*: _Build consistency across platforms (Including Windows):_ Currently Imake does a good job for build consistency across *nix variants, however there is an entirely different set of mechanics for dealing with builds on Windows, which few people really understand. To make matters a bit more confusing, is that the mechanism by which we build & test on Windows is quite non-standard which presents an issue as condor becomes a more open source project. This plurality causes several issues in maintaining two desperate build files, with completely different mechanisms. It would be in the best interests for the group in the long run to employ a single build mechanism which has support on all condor platforms.
-*: _Support for unit testing within the build:_ For the purposes of testing it is advantageous to have a build tool which supports running automated unit tests as part of a "unit" build.
+*: _Support for unit testing within the build:_ For the purposes of testing it is advantageous to have a build tool which supports running automated unit tests as part of a "unit" build, with a minimal amount of external overhead.
-*: _Packaging:_ Many build systems provide automated packaging for it's native environment. This can be highly useful as it eliminates and automates custom build steps and scripts and makes it easier to maintain. Having this requirement can reduce the overhead on condor developers and allow them to focus on bug fixes. It also allows condor to get out of the packaging business and simplifies the consumption for downstream folks.
+*: _Packaging:_ Many build systems provide automated packaging for it's native environment. This can be highly useful as it eliminates and automates custom build steps and scripts and makes it easier to maintain. Having this requirement can reduce the overhead on condor developers and allow them to focus on bug fixes and new features. It also allows flight worthy to get out of the packaging business and simplifies the consumption for downstream folks.
{section: Possible Options }
If we use the afore mentioned goals as hard requirements, then it eliminates a lot of possible choices, and only a couple remain:
@@ -17,7 +17,7 @@
*: _bjam:_ Created as a replacement/extension to perforce JAM it has it's own syntax and supports numerous platforms, it also does not provide flexible packaging features, and lacks the transition glue to move from an auto-tools style build.
-*: *CMake - winner:* CMake is widely adopted in the open source community as a x-platform replacement for auto-tools style builds. It has it's own Macro-style syntax, but unlike the afore mentioned tools it is a generator similar to Imake and it works with existing tools (make, visual studio). Another powerful tool build alongside is CPack which allows for various methods of packaging, across multiple OS distributions.
+*: *CMake - winner:* CMake is widely adopted in the open source community as a x-platform replacement for auto-tools style builds. It has it's own Macro-style syntax, but unlike the afore mentioned tools it is a generator similar to Imake and it works with existing tools (make, visual studio). Another powerful tool in the "CMake warchest" is CPack, which allows for various methods of packaging, across multiple OS distributions.
{section: Plan and phases}
@@ -116,15 +116,24 @@
6.) make || open the visual studio project.
{section: Contributing}
-All of the updated cmake files exist under src/new_build and are open to contribution. The current branch tracks against master and all files under new_build are a series of softlinks against the originals to allow for easy merge-outs, and to allow for parallel builds in case it is needed. There are a substantial number of changes and cruft removal in this branch so there may need to be a bit of work to get the old build to function in this new branch, as I have not made it a priority atm.
+All of the updated cmake files exist under src/new_build and are open to contribution. The current branch tracks against master(7.5 series) and all files under new_build are a series of softlinks against the originals to allow for easy merge-outs, and to allow for parallel builds in case it is needed. There are a substantial number of changes and cruft removal in this branch so there may need to be a bit of work to get the old build to function in this new branch, as I have not made it a priority atm.
*Conventions*
*: #include <lib>/header.h (no more relative includes)
*: Compiles fully in C++
-*: Proper use of extern “C”
+*: Proper use of extern
*: Minimal linkage, explicitly specify
*: Platform specific files are suffixed as to allow glob macros to add to target (.windows, .unix)
+{section: Packaging}
+CMake's compliment, CPack, supports a large number of packaging types which can be found {link: http://www.cmake.org/Wiki/CMake:CPackPackageGenerators here}, and it is currently in its infancy in the code base. There are two targets which are created when you include(CPack):
+
+{code}
+make package
+make package_source
+{endcode}
+
+The road ahead is to create a stub'd out CPackOption.cmake.in file and use cmakes configure options to fill in the gaps based on the target platform and environment, thereby reducing the cruft in the master CMakeLists.txt and providing the wiz-bang feature of platform specific package generation.
{section: Links}
{link: http://www.cmake.org/cmake/help/documentation.html CMake Official Documentation}
