Interesting. I like some of the stuff you have here. I can only do so much in Parts wrapping SCons, some of it has to be in the core
What I would like to know as I did not see it in the example right off is, how do you deal with lots of components. One feature I have in Parts and often see people implement in different ways in raw SCons is passing information between different files. The common case of this is when link a lib file in to your main program you don’t know what the real name of the lib file is or you want to be protected from having a build break because a component for whatever reason change the output name. Also your benchmarks… is this 32-bit or 64-bit. I missed it on the webpage. I ask as you show Scons blowing up a 100K node. I know I have a build here with Scons at 200K worth of files node as it works fine ( build in about 2 hours with 24 cores and 16GB of memory for SCons and the tools/compilers.) Jason From: Scons-dev [mailto:scons-dev-boun...@scons.org] On Behalf Of Constantine Sent: Tuesday, January 13, 2015 3:09 AM To: SCons developer list Subject: [Scons-dev] SCons-like build system Hello SCons developers, I intensively used SCons from 2003 till 2010. And I contributed some changes to SCons 0.98 (see http://www.scons.org/CHANGES.txt) I think that SCons is good build system, but from my point of view it has some scalability problems. Initially I implemented an extension to SCons to solve some problems (something similar to the Parts). But to solve other problems the core implementation should be significantly changed. So I implemented a new SCons-like build system trying to solve these problems. I named it Aqualid<https://github.com/aqualid/aqualid>. To compare Aqualid with others I tested three build systems: SCons, Waf and Aqualid On the following page you may review results for different project sizes (100, 1000, 10000 and 100000 C++ source files): https://github.com/aqualid/aqualid/wiki/Benchmark-results-for-v0.5 Aqualid uses less memory because it fully releases finished nodes. That's the reason why you can see almost the flat graph for large projects. The tests sources and Aqualid itself can be found here: https://github.com/aqualid/aqualid/releases From end user point of view SCons and Aqualid build systems look more or less similar. But there are many differences: - By default it uses the current OS environment to initialize tools - But it's easy to customize OS environment for specific tool or specific version of tool - Each tool has own subset of options, for example CPPDEFINES is defined only for C/C++ tool - Output build directory can be set to any place (even outside of project) for the whole project or for specific nodes - API is different from SCons - There are no emitters and scanners, all targets and implicit dependencies are identified during the build step - Nodes are processed dynamically while other nodes are being built - Target type is not restricted to file, it could be a simple string, int, bool or any other type (it depends from only from builder) - Node may even have no targets at all - There is no strict rule for the project root (like SConstruct), any build script may be used as the project root and many others... You can find several usage examples here: https://github.com/aqualid/aqualid/wiki/An-introduction-to-Aqualid I will be glad to discuss/share any implementation details and issues. Probably something could be reused in SCons. Thank you. Best regards, Konstantin.
_______________________________________________ Scons-dev mailing list Scons-dev@scons.org https://pairlist2.pair.net/mailman/listinfo/scons-dev
