This patch enables support for a Python-based build system I've been working on called Cake. It uses most of the original SConscript's. Only the SConstruct file is duplicated. This patch works with SConstruct revision 42588.
Incremental do-nothing builds can be up to 10x faster (eg. Scons -> 30 seconds, Cake -> 3 seconds). Full builds may only be slightly faster (eg. SCons -> 7 minutes, Cake -> 6 minutes).
At the command line type this to build all available build variants:
python cake/run.py
Or eg. this to build a specific variant:
python cake/run.py platform=windows architecture=x86 compiler=msvc
Type this to generate MSVC 2008 project files in the '../build/projects' directory:
python cake/run.py -p
After running cake there will be an extra directory '../cache' that contains a cache of build scripts and dependency files.
There's no need to run vcvars.bat to compile for Windows. Cake will find the MSVC, Windows SDK and MinGW compiler install paths from your registry.
There's no problem with command line limits when compiling with MinGW on Windows.
It can build executables with identical sizes to SCons but at the moment it won't because I'm appending '-release' to the build folder names.
It would be easy to provide a debug build variant with BF_DEBUG=1 but I haven't because the BF_DEBUG switch seems to be broken on some platforms.
The only build variant I haven't added support for is 'linuxcross'. If you find Cake appealing I'd be happy to add it.
It would be possible to share the SConstruct with Cake by splitting it into multiple files, eg. SConscript-Config SConscript-Compile SConscript-Install and SConscript-Package. I'd also be happy to do that or any other build system maintenance relating to Cake.
Regards,
Stuart McMahon.
Cake Build System
http://sourceforge.net/projects/cake-build/
Description
Event Timeline
Hi Stuart, the issue with having more build systems is it gives us overhead long term.
- People who maintain branches have to add support (before or after merge).
- Adding official new features needs to support.
- Developers in IRC need to known how to resolve linking. header, configuration in more build systems.
People who care about fast builds can use cmake, Im not much a fan of scons but for release builds it seems to work well.
We used to have 4 build systems and it was really a pain to maintain (manually maintained MSVC project files, Makefiles, CMake, SCons), now we only have CMake & SCons.
so nothing against Cake - but I'm really not looking for another build system for blender unless it offers significant benefits and can replace an existing build system.
Hi Campbell,
Thanks for your reply.
I guess the theory is it could replace both of your existing build systems provided it could match the speed of CMake and retain the flexibility of SCons.
Remember that at the moment Cake is simply using the existing SConscripts so the only extra maintenance is:
- The duplication of the SConstruct (which can be fixed by splitting the SConstruct as described above).
- The use of explicit 'prerequisites' instead of automatic library/header resolution when a blender executable needs to link with an internal blender library/header. I can fix those cases manually when they crop up. Currently there are only 3 (makesdna, makesrna, cycles).
When it comes to replacing CMake with Cake the hurdles I see are:
- Cake can only generate MS Visual Studio project files. I would need to add project generation options for each of the CMake project types blender coders used.
- Cake won't build incrementally as fast as CMake but it could be improved. Currently though 3 seconds versus 1 second might be an acceptable tradeoff for the ease of only maintaining one build system.
A first step could be to put cake in a 'blender/caketrial' directory with a note that it's not officially supported to let people trial it as an alternative to SCons. If it ends up being faster and more stable it could replace SCons. I could also fix any bugs found which would really help the development of Cake.
Later steps could be to improve the 'blender/../install' process:
- Only copy files that have changed (eg. those in 'blender/release/scripts').
- Only extract files that have changed (eg. those in 'lib/windows/release/python32.tar.gz').
- Remove stale files from the installation directory.
Regardless of whether you choose to try it, getting Cake to build Blender has helped its development immensely.
Regards,
Stuart McMahon.
Hi Again Stuart,
I doubt this could replace CMake, since we use...
- project file integration for eclipse/qtcreator/msvc/... others
- rich set of `Find` modules, complimented with some of our own we include.
- CTest, not heavily right now, but we use for import/export tests before release.
- CPack, not for official builds but we have put time into getting RPM/DEB packages building.
For me this is a bit arbitrary - if someone writes support for Jamfiles, waf, etc, adding any of them should give a big benifit to the blender developers (taking into consideration the extra time taken they need to be maintained)
Your suggestions to have this on trial may be reasonable, what I still miss is an existing developer happy to at least ensure it works once in a while and do any maintenance.
Also, Im not surprised you managed to have a build system faster then SCons, but would be curious to know how it compares with scons running with more optimal settings.
eg: http://stackoverflow.com/questions/1318863/how-to-optimize-an-scons-script
Hi Campbell,
With the options 'scons --max-drift=1 --implicit-deps-unchanged' I get the following results for a do-nothing build:
Scons -> 20.3 seconds (or 20.9 seconds with --implicit-cache)
Cake -> 3.2 seconds
I understand you need an existing developer to review the changes and instigate a trial so I'll leave the patch here and update it as the SConstruct changes (usually doesn't take long).
If someone has time to take a look at it in the future, cool, otherwise there's no harm done. It's taking a minimal amount of my time to update it and hopefully not too much server space to store it.
Regards,
Stuart.