[Scons-dev] SCons-like build system

[Dirk Bächle]

Hi Constantine,

thank you very much for the note about your project "Aqualid". I already had a short look at your benchmark, and plan to also check 
the actual sources soon. Allow me to give you a few pointers as well:

In the recent past we have done some extensive performance analysis and profilings for SCons, you can find the details and results 
at http://www.scons.org/wiki/WhySconsIsNotSlow . I also gave a talk about this ( http://www.pycon.fr/2014/schedule/presentation/25/ 
, slides at https://bitbucket.org/dirkbaechle/scons_talks ), unfortunately the video hasn't been edited/published yet. As a 
follow-up of these investigations I have prepared a patch that switches SCons (especially the Node class) to using slots, in order 
to reduce the overall memory consumption. If you're interested in trying it out with your benchmark, you can get a copy with

   hg clone http://bitbucket.org/dirkbaechle/scons_experimental -r switch_node_to_slots

. See also https://pairlist2.pair.net/pipermail/scons-dev/2014-December/002107.html for more infos about this.

Once these changes are in, we'll integrate the stubprocess.py wrapper for speeding up clean builds...as described on the 
WhySconsIsNotSlow page.

We're also currently redesigning the ways we handle Tools and Toolchains, trying to make things more flexible for the user. Maybe 
you want to join this discussion?

Given the upcoming improvements in our codebase it might also make sense that you, Jason Kenny from the Parts project 
(parts.tigris.org) and our project managers Gary and Bill stick their heads together. I have a vision of using the SCons framework 
as building block for: the classic "scons" script, "parts" and "aqualid" as well. We could try to provide a "stack" of build 
systems, where users can migrate from "aqualid" -> "scons" -> "parts" whenever their requirements grow.
Just as an idea...and we already have some plans to move stuff from parts into SCons. If we want to sort of combine our forces, 
now's the time to talk about it. ;)

Best regards,

Dirk

On 13.01.2015 10:09, Constantine wrote:
> Hello SCons developers,
>
> I intensively used SCons from 2003 till 2010.
> And I contributed some changes to SCons 0.98 (seehttp://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 itAqualid  <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 at scons.org
> https://pairlist2.pair.net/mailman/listinfo/scons-dev
>