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@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@scons.org > https://pairlist2.pair.net/mailman/listinfo/scons-dev > >
_______________________________________________ Scons-dev mailing list Scons-dev@scons.org https://pairlist2.pair.net/mailman/listinfo/scons-dev