A Cross-Platform Build Chain
by Joti Carroll · in Torque Game Engine · 10/06/2005 (5:58 pm) · 13 replies
I am currently completing development of a cross-platform build chain using CMake (www.cmake.org) and hoping to gauge the willingness of the Torque community towards adopting this software.
The idea behind the CMake build chain is to replace the mulitple sets of build files (makefiles, dsp & dsw, etc...) for the various different platforms with one consistant set of text files (CMakeLists.txt) placed in each directory of the source tree. When a person wishes to install TGE on a computer they must first download the CMake client for that platform (almost all platforms are supported and the clients are free and the source is available) and run the client across the source distribution to generate the build files for that particular platform (similar to autoconf but completely cross-platform).
The most obvious advantage of this methodolgy is to limit the fragmentation that can occur in development process when one platform is popular for developers and new source and resources enter the code-base for that platform but fail to be propagated directly into the build-chain of other platforms. Once established the CMake build chain is very simple to operate and update requiring almost no platform specific knowledge.
A common build-chain also presents the possibility to do reliable automated nightly builds of the source-tree for testing purposes seeing as any additions to the CVS and consequent build-files will automatically apply to each different platform. CMake is natively a C/C++ compiler but can be envoked to compile almost any other language automatically (doxygen, java, assembly, latex, etc...).
A further advantage of using CMake is relative ease at which the source-code can be adapted to other platforms. CMake is very proficient at determining the particulars of a machine (operating system type, processor type, location of development libraries, etc...) and thus provides information suitable to make the necessary switches between the required source-code and resources at the build-file level.
So far I have completed a CMake build-chain for the CVS release of TGE (as of a few days ago) that works for Windows but not Mac or Linux (due to the missing methods in platformX86UNIX and platformMacCarb). I have also completed a build chain for a slightly modified version 1.3 (I have applied fixes to make it compile on different versions of gcc in Linux (3.3 - 4.0) and also OSX). The build chain for 1.3 compiles on all platforms but I have not been able to circumvent the segmentation faults on Linux at this stage.
I have several questions:
- Is the Torque community interested in adopting this CMake build-chain?
- If so, should the 1.3 or CVS version be adopted or both?
- What strategy should there be for integrating these new CMake files into the CVS?
I will make available an entire version of the source-code within the next week, does anyone know of an approriate place I could upload the software (ie. not public) which is 100+Mb's?
David McKinnon...
Post-Doctoral Research Fellow (ACID)
www.acid.net.au
The idea behind the CMake build chain is to replace the mulitple sets of build files (makefiles, dsp & dsw, etc...) for the various different platforms with one consistant set of text files (CMakeLists.txt) placed in each directory of the source tree. When a person wishes to install TGE on a computer they must first download the CMake client for that platform (almost all platforms are supported and the clients are free and the source is available) and run the client across the source distribution to generate the build files for that particular platform (similar to autoconf but completely cross-platform).
The most obvious advantage of this methodolgy is to limit the fragmentation that can occur in development process when one platform is popular for developers and new source and resources enter the code-base for that platform but fail to be propagated directly into the build-chain of other platforms. Once established the CMake build chain is very simple to operate and update requiring almost no platform specific knowledge.
A common build-chain also presents the possibility to do reliable automated nightly builds of the source-tree for testing purposes seeing as any additions to the CVS and consequent build-files will automatically apply to each different platform. CMake is natively a C/C++ compiler but can be envoked to compile almost any other language automatically (doxygen, java, assembly, latex, etc...).
A further advantage of using CMake is relative ease at which the source-code can be adapted to other platforms. CMake is very proficient at determining the particulars of a machine (operating system type, processor type, location of development libraries, etc...) and thus provides information suitable to make the necessary switches between the required source-code and resources at the build-file level.
So far I have completed a CMake build-chain for the CVS release of TGE (as of a few days ago) that works for Windows but not Mac or Linux (due to the missing methods in platformX86UNIX and platformMacCarb). I have also completed a build chain for a slightly modified version 1.3 (I have applied fixes to make it compile on different versions of gcc in Linux (3.3 - 4.0) and also OSX). The build chain for 1.3 compiles on all platforms but I have not been able to circumvent the segmentation faults on Linux at this stage.
I have several questions:
- Is the Torque community interested in adopting this CMake build-chain?
- If so, should the 1.3 or CVS version be adopted or both?
- What strategy should there be for integrating these new CMake files into the CVS?
I will make available an entire version of the source-code within the next week, does anyone know of an approriate place I could upload the software (ie. not public) which is 100+Mb's?
David McKinnon...
Post-Doctoral Research Fellow (ACID)
www.acid.net.au
About the author
#2
10/08/2005 (2:33 am)
Speaking after being on IGC for 18+ hours today - sounds great, e-mail me about it please! I'll respond to this and many other forum threads when IGC is over. :) 
#3
10/09/2005 (3:56 am)
I was actually thinking about throwing something together in NAnt and CruiseControl.NET to do fully automated continuous builds, but if we can get MacOS X support out of this, all the better! Another one that seems useful is SCons, though I haven't looked at it as much. 
#4
12/11/2010 (12:54 am)
Has anybody made any progress in using CMake with TGE? Thomas Dickerson and I are thinking of adding CMake, and I know Josh Engebreston was talking about it as part of the Karma project (now sadly deceased?). Before we dive in, it'd be great to know if anyone else has figured it out. 
#5
12/21/2010 (2:25 am)
Ironic/depressing that this was the first and only thread I stumbled across while investigating the same thing.
#6
No attention was put for multi-platform compilation yet, meaning all is VS centric and no conditionals for other IDEs/Platforms have been added, that was to be the next step, but at least you can easily configure projects for VS 2005,2008 or 2010.
It was tested with VS2010 Professional.
You can grab the files from here, just extract the files over a fresh (or fairly unmodified) installation of TGEA 1.8.2 and then use CMake to generate.
It would be great if GG adopted CMake, hopefully this contributes to that.
02/03/2011 (10:45 am)
I have a working CMake setup for TGEA 1.8.2, I started working on it back when I though that was the last version I'd see the code for, now I got T3D, so I went and finished it to get an idea of what would it take for T3D.No attention was put for multi-platform compilation yet, meaning all is VS centric and no conditionals for other IDEs/Platforms have been added, that was to be the next step, but at least you can easily configure projects for VS 2005,2008 or 2010.
It was tested with VS2010 Professional.
You can grab the files from here, just extract the files over a fresh (or fairly unmodified) installation of TGEA 1.8.2 and then use CMake to generate.
It would be great if GG adopted CMake, hopefully this contributes to that.
#7
02/03/2011 (11:27 am)
Rodrigo, that's encouraging to hear. How long did it take you to set this up? It's unfortunate that there is no easy way to automate retrieving the settings from an XCode or CodeBlocks or VS project into a CMake file.
#8
I cannot give you an accurate estimate as I started a while ago, got frustrated and then came back to it recently, all in all, I'd say, it took about a week, had to do a lot of backtracking from VS project files for the external libraries, and I remember getting the source files for the engine into source groups as a very tedious task.
I've been thinking that perhaps, using XPath or some sort of xml converter it could be possible to create CMake files out of vcproj files which are xml files anyway.
02/03/2011 (1:02 pm)
Hi Thomas,I cannot give you an accurate estimate as I started a while ago, got frustrated and then came back to it recently, all in all, I'd say, it took about a week, had to do a lot of backtracking from VS project files for the external libraries, and I remember getting the source files for the engine into source groups as a very tedious task.
I've been thinking that perhaps, using XPath or some sort of xml converter it could be possible to create CMake files out of vcproj files which are xml files anyway.
#9
02/03/2011 (1:37 pm)
I bet I could write a Python script to read project files and make that a bit easier. pbxproj files seem to have a C-like syntax.
#10
02/03/2011 (2:00 pm)
I was thinking about XSLT for .vcproj files, might be even easier, but I don't know, haven't looked that much into it yet.
#11
02/03/2011 (3:19 pm)
I think we'd need different strategies for each IDE's format, but Python would make it easy to tie everything together, and we could certainly use it for reading xml.
#12
I'd second Pythonas a general solution - there are certainly XML libraries we could make use of for an XSLT solution for vcproj files.
Getting all the code files in there is just a matter of grunt work, and we could even do some automation in that regard, to generate CMake fiels for all the files in a directory.
I need to do more reading up on CMake :P.
02/07/2011 (1:24 am)
Thanks for posting, Rodrigo!I'd second Pythonas a general solution - there are certainly XML libraries we could make use of for an XSLT solution for vcproj files.
Getting all the code files in there is just a matter of grunt work, and we could even do some automation in that regard, to generate CMake fiels for all the files in a directory.
I need to do more reading up on CMake :P.
#13
02/07/2011 (8:19 am)
Sure, I have no objection, ideally to me, CMake would either be adopted by GG or once there is an initial CMake hierarchy, it would be trivial to make manual changes each time a new version comes out, then of course, I don't know how many people have the custom of keeping all source under version control at home. 
Torque 3D Owner Stephen Zepp