It already does that... On Fri, Dec 25, 2015 at 11:30 AM, Jonathon Reinhart < [email protected]> 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" < > [email protected]> 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 >> [email protected] >> https://pairlist2.pair.net/mailman/listinfo/scons-dev >> >> > _______________________________________________ > Scons-dev mailing list > [email protected] > https://pairlist2.pair.net/mailman/listinfo/scons-dev > >
_______________________________________________ Scons-dev mailing list [email protected] https://pairlist2.pair.net/mailman/listinfo/scons-dev
