Build Modernization

Not logged in

• Browse
• Help
• Home
• Login
• Reports
• Search
• Timeline
• Wiki

• Contents
• Diff
• Text

Goals and Objectives

• 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, 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 and new features. It also allows flight worthy to get out of the packaging business and simplifies the consumption for downstream folks.

Possible Options

• SCons: SCons is a fairly powerful tool build atop of a python, which allows you to pretty much do anything. The only major disadvantage is the issue of packaging, and size of adoption within the open source community. There are also issues when dealing with exiting auto-tools style builds.

• 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 in the "CMake warchest" is CPack, which allows for various methods of packaging, across multiple OS distributions.

Getting Started

2.) Checkout origin/V7_5-cmake-stage-publicbranch, for windows you will need git 1.6.4 or greater.

3.) cmake ./CMakeLists.txt or run cmake-gui (NOTE - will default to PROPER build on *nix, for platform specific configs see nmi_tools/glue/SubmitInfo.pm)

4.) Now you can run make or open the visual studio solution file.

Windows Only:

Prior to building for the 1st time there are some prerequisites that you will need to perform

5.) Install the lastest platform SDK and reopen the solution

• http://msdn.microsoft.com/en-us/windows/dd146047.aspx
• Currently it is http://www.microsoft.com/downloads/details.aspx?FamilyID=e6e1c3df-a74f-4207-8586-711ebe331cdc&displaylang=en

6.) Download and install WiX 3.0 on your windows machine

• http://wix.sourceforge.net/downloadv3.html

7.) Patch your version of cmake/cpack to enable wix support by dropping the following into your cmake path. You may want to verify with a diff tool such as beyond compare when updating.

• https://docs.google.com/leaf?id=0Bzq0eFfVveNqZjI4OGEyYTEtNzZhMS00MDI5LWI0YWEtZmNlZjVjMzQ1Mjc0&sort=name&layout=list&num=50

8.) Open Tools->Options under "Projects and Solutions" click on VC++ Directories and add the following to the Executable directories

• $(SolutionDir)\msconfig
• Move $(PATH) to the bottom as sometimes C:\cygwin\bin is in the $(PATH) which can cause issues with condor's bundled binaries.

9.) Open and build.

Contributing

Conventions

• #include <lib>/header.h (stage 2)
• Compiles fully in C++ (stage 1)
• Proper use of extern (stage 1)
• Minimal linkage, explicitly specify (stage 2)
• Platform specific files are suffixed as to allow glob macros to add to target (.windows, .unix) (stage 1)
• condor specific macros are located under build/cmake (stage 1)

Packaging

make package
make package_source

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.

TODO

Windows Gotchas

@SET FrameworkDir=Framework32
@SET FrameworkVersion=v2.0.50727

@SET FrameworkDir=C:\Windows\Microsoft.NET\Framework
@SET FrameworkVersion=v2.0.50727
@SET Framework35Version=v3.5

Also, a portion of the PATH variable may have an incorrect entry which can lead to problems in the CMD interpreter. If in the same file you see a PATH entry like:

%FrameworkDir%\%Framework35Version%\Microsoft .NET Framework 3.5 (Pre-Release Version);

%FrameworkDir%\%Framework35Version%\Microsoft .NET Framework 3.5 SP1;

Environment variable expansion

CMD \V:ON \E:ON

Links

CMake Official Documentation

Google Code Search for open source examples

This work is supported by NSF under Cooperative Agreement OAC-2030508 as part of the PATh Project. Any opinions, findings, and conclusions or recommendations expressed in this material are those of the author(s) and do not necessarily reflect the views of the NSF. Site built using CVSTrac.