[Scons-dev] SCons-like build system

Constantine voidmb at gmail.com
Tue Jan 13 17:28:20 EST 2015


Thank you Dirk for the very interesting response.
I will review closely all the links.

I definitely see improvements in SCons performance during the last years.

I think that moving to __slots__ is good way, it will improve memory
consumption, but for the large projects it still could consume a lot of
memory.

Aqualid uses __slots__ since initial version, but it used a lot of memory
on large projects in the past. Fortunately, I resolved this issue with
quite simple fix. I added a function Node.shrink() (see
https://github.com/aqualid/aqualid/blob/master/aql/nodes/aql_node.py)
It simply resets all already unneeded attributes to None.


*>> 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?*
Yes. As example I can explain how it works in Aqualid. I don't have a link
to documentation yet. I'm still writing user guide.


*>> We could try to provide a "stack" of build systems, where users can
migrate from "aqualid" -> "scons" -> "parts" whenever their requirements
grow.*
I fully support this idea. I remember there was a discussion of similar
ideas about seven years ago. Email thread "SCons Future Directions and
Thought"

Thanks!
Best regards,
Konstantin,

On Tue, Jan 13, 2015 at 9:55 PM, Dirk Bächle <tshortik at gmx.de> wrote:

> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist2.pair.net/pipermail/scons-dev/attachments/20150114/e040b689/attachment.html>


More information about the Scons-dev mailing list