Hi In the scons-build branch, I've just pushed a set of 11 commits that theoretically get 93 out of 105 gbuild modules (88.57%) automatically converting to gbuild.
The "gotoSCons" converter and the SCons infrastructure in that branch have now been developed to such a level that a module can be automatically converted from gbuild to SCons, from where it can use SCons for all of the following: Building C/C++ objects Linking shared libraries, static libraries, and executables Building JUnit tests and running them Building Google Tests and running them Building .component files with XSLT Running Ant sub-builds Delivering "package" files such as headers Even doing the impossibly difficult 5 step "AllLangResTarget" (.src -> merged .src -> .srs -> .res for each language). I still have to implement Jar, Zip, UnoApi, WinResTarget and SdiTarget, but I think only Jar and Zip are worth implementing automatic conversion for, as SdiTarget and UnoApi are only used in 5 places each, and WinResTarget in only 2 places, which makes manual conversion for them easier. The hardest conversions are already done. Where does this leave us? The gotoSCons converter can't support a number of features, like non-deterministic constructs (ifeq ($(GUI),UNX)), custom make rules, etc. A module can only be automatically converted if it doesn't use the unsupported features. Currently, 35 modules use only supported features, and can be converted automatically (this should increase to 39 modules when I add Jar and Zip conversion). Another 58 modules use non-deterministic constructs or custom make rules. Converting those 58 could be done through a semi-automated process, which involves editing the gbuild files to remove the unsupported features, running the automated conversion on what is left, then manually patching what was removed into the conversion results. Sometimes this is quick and easy, at other times probably not. The final 12 modules use unsupported targets requiring a longer and mostly manual conversion to SCons, though even there the supported targets could be converted automatically. The SCons infrastructure does require some cleanup, as I was learning while developing, and we still need library naming conversions, tests on Linux/WIndows/Mac, etc. The more I've used SCons, the more I've liked it. I've even started using it in my own projects at work now. I've found a way to solve every problem I've encountered, and the SCons developers have been helpful when I asked them questions. Complex functionality like header dependency scanning, automatic directory creation for output files, using @responsefile for long command lines when necessary, and other features gbuild implements manually, all work in SCons automatically. In 1816 lines of code, our SCons infrastructure implements what took gbuild 9418 lines, and SCons is far more readable and maintainable (even in its current messy state). The plan isn't to merge this to trunk any time soon. Rather the idea is to develop the converter even further, then when it's complete enough, convert as many gbuild modules to SCons. Then measure performance of building those modules en-masse with SCons alone - if there are performance problems at that stage, they are only going to get worse with more modules. The real test however is converting the other 78 dmake modules to SCons. 37 of them are 3rd party "externals" like jpeg and zlib, which have their own build systems that we just call, so conversion is relatively easy. The other 41 modules are hard to convert, but gbuild is one of the reasons that they were hard, and where SCons is expected to make the greatest difference. Only once we are building without dmake, without gbuild, without build.pl, without Cygwin, on all platforms, then it would be the right time to merge to trunk. If at some stage in this process we are unhappy with SCons, and some better build system can be found, it shouldn't be difficult to change to it. The converter could output files for that other build system instead; at present it's only 498 lines of code in 1 file, that are involved in writing SCons build files, all we would need is a similar file for that other build system. Build systems are not the most exciting part of development, but bad build systems make development painful, and as a large multi-platform project, we build a lot. We answer build-related questions on the mailing lists too often, and new contributors are put off by the current build system. A lot of what we want to do with AOO, such as ports to Win64, AArch64, newer MSVC versions, and so on, also involve build-related changes. Damjan