[Scons-dev] scons daemon

[Jonathon Reinhart]

Instead of a daemon, could SCons cache the dependency graph in a format
able to be quickly reloaded? If any of the files from which the DAG was
generated changed, the cache would be (partially?) invalidated. It seems
like a natural application of SCons' existing dependency-checking
capabilities; I'm just not sure how much of a speedup this might provide.
For projects where a lot of parsing is involved in generating the DAG, it
could be big.

Jonathon Reinhart
On Dec 24, 2015 6:57 PM, "Schleimer, Ben via Scons-dev" <scons-dev at scons.org>
wrote:

> Hi,
>    I was wondering if anyone else was interested in such a feature.
> I found on google that it was discussed before (gmane.org seems to be
> down right now) but that nothing was actually implemented.
>
> The reason to have a build daemon is to keep the dependency tree in memory
> for rebuilds and to try to keep the builds up to date as quickly as
> possible. Build systems like gradle and bazel seem to rely on a daemon (and
> VS C# and Eclipse uses background compiles extensively)
>
> My tentative thoughts about how to design this are as follows:
> 1) Build a wrapper py script that peers with scons.py to make it a bit
> simpler at first
> 2) when the daemon starts, it builds the dependency tree and extracts a
> list of all source files. It uses watchdog (or some other inotify-like
> library) to watch for changes in all of the source files.
> 3) Whenever a source file is changed, the file is copied to a temporary
> directory
> 4) As the source files change, the daemon rebuilds the dependency tree in
> memory
> 5) After an idle period, the daemon begins building the out of date
> targets. As it builds each target, the target is copied to it's proper
> location in the original source tree. During the build, dependency tree
> updating and source file copying is disabled but the watched files are
> still marked as dirty
> 6) Once the build is complete, dependency tree updating and source file
> copying are re-enabled.
>
> I am just starting to go through and examine all of the core scons source
> in depth but does this sound like a reasonable approach? What is missing?
> Are there dependency situations which could cause this scheme to fail?
> What about the pre and post build scripts?
>
> Sincerely,
> Ben
>
>
> _______________________________________________
> Scons-dev mailing list
> Scons-dev at scons.org
> https://pairlist2.pair.net/mailman/listinfo/scons-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist2.pair.net/pipermail/scons-dev/attachments/20151225/b154a5bc/attachment.html>