[Scons-dev] scons daemon

[Bill Deegan]

It already does that...

On Fri, Dec 25, 2015 at 11:30 AM, Jonathon Reinhart <
jonathon.reinhart at gmail.com> wrote:

> 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
>>
>>
> _______________________________________________
> 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/bf14a3cb/attachment.html>