Build automation by using platform specific project files or by using project generators?_问答_开发者

There are some build systems that are able to generate platform specific project files like Visual Studio sln,vcproj,开发者_如何学JAVAvcxproj files or XCode xcodeproj projects under OS X.

One of them is CMake but I found out that the support for this is quite limited, buggy and that is very hard to keep it updated with newer versions (like VS 2010).

Also, at least CMake, is missing support for property pages for Visual Studio and this makes harder to manage and change project wide configurations - like enabling/disabling Code Analysis for all projects.

An workaround to the above issue is to manually create project files for each platform - in my case there are only two, but even with more the number should not be so big.

It is quite easy to call the platform specific build commands into a generic build automation script. For example I used waf (Python) for automating this on few projects without using its own build part.

I would like to see what you would choose between: trying to repair/maintain project generators or keeping separated project files?

Here's what we do, it might not be the best way, but it works really good for us and we found that it's not too hard to maintain, maybe you find it interesting.

Our main platform is windows, nearly all development is done in the VS IDE. For the other platforms (only some linux flavors for now) we use CMake exclusively. Basically we chose the "trying to repair/maintain project generators" way, but with Visual Studio project files as a starting point.

we use visual studio project files as a container for all files in a project
all build options are set in property sheets, each project has a standard set and eventually some extra sheets to pull in certain libraries etc
we have some simple scripts that allow to add/remove property sheets in one batch
all property sheets have a cmake counterpart; both are kept in the same directory, and if we update one, we update the counterpart as well, always. This is not done with a script, and I admit this is the 'complicated' part: although we realy heavily on macros, there are always options that are available on one platform but ot on the other.
we have a script that converts vcproj files into cmake files, it basically creates a cmake file which includes the corresponding cmake property sheets and which contains all source files the vcproj has.
last but not least I wrote a build server that runs on all platforms we use. It builds using msbuild or cmake, and it is the key in keeping this system working: each change we make triggers a build+tests on at least two machines, so we know immedeatly if all is stil fine.

We recently started using VS2010, and the migration only took about a day: first we let VS convert all our projects and property sheets, then we made some adjustments to the scripts to handle the new xml file formats.

Edit

sorry but I cannot post the scripts, company policy, hope you understand. A bit of pseudocode is no problem though. Adding/removing property sheets in VS2008 project files goes like this:

foreach proj in projectfiles //list of vcproj files
  foreach config in configuration //configurations eg 'Debug|Win32, Debug|x64'
    f = OpenFile( proj );
      //find start of Configuration element, then get what's after InheritedPropertySheets=
    propsheets = GetPropSheetsForConfig( f, config );
    propsheets = DoAction( action, args, propsheets ); //action is add/remove/.. with argument args
    SetPropSheetsForConfig( f, propsheets );

For the CMakeLists files this is pretty much the same, except the script works on the 'include(..)' lines.

Convertig from vcproj to CMakeLists:

f = OpenFile( proj );
projname = GetProjectName( f );
sources = GetSourceFiles( f ); //all File/RelativePath elements under Filter 'Source Files'
sources = CheckFilter( sources ); //apply rules to include/exclude platform specific files
propsheets[] = GetPropSheetsForConfig( f, configs[] );

fout = CreateCMakeFromProj( proj ); //CMakeLists.txt in corresponding directory
WriteCMakeHeader( fout, projname );
WriteCMakeSources( sources );
WriteCMakeIncludes( configs[], propsheets[] ); //write includes, conditional on CMAKE_BUILD_TYPE

The build server is quite advanced material now, but in the beginning it was just a TCP listener:

await connection
get optional arguments (property sheets/action)
update of the repository
eventually run the batch script for the property sheets with the given arguments
start command line full rebuild + tests, capture output in file
parse file for lines containing 'error', mail results

All my projects are cross platform, and my preference is the workaround. With Scons maintaining a cross platform project is little or no work. One good defined environment will work for most project, and use a template for each project/subproject. You also have the benefit of complete control over the building process, allowing you to use domain specific languages, do code generation, manage source control, with ease.

Learning Scons is dead simple when you know python, without knowing python, you are disconvering two great technologies not one ;)

We use boost.build for our platform projects. It works well for C++ library projects. We like it because we only need to maintain one script and it integrates with Boost.Test well.

It does have a very steep learning curve and the documentation is quite poor. But it does its work well on Windows and Linux, the two platforms that we work on.