continuous builds

[Peter Collingbourne]

Hi,

I've been working on adding a continuous mode to Ninja. The mode uses
file watching to try to continuously keep a target up to date without user
intervention.

My branch with the changes is:
https://github.com/pcc/ninja/tree/continuous

It's not ready to go in yet (there are a number of known issues, and it has
no tests) but I wanted to publish it early in case anyone is interesting
in testing it. I've tested it against Chromium and LLVM and it seems to
correctly handle changes to source files.

Known issues:
- Probably does not build on any platform other than Linux.
- Fails to take into account changes to depfiles (so e.g. if a #include line is added
to a source file after the start of the build, that source file will not be rebuilt
if the header file changes later).
- Cannot handle changed generator input files correctly:
- Changes to generator input files are only observed at the start of the build.
- Updating the build.ninja file does not work with CMake; it will get into an
infinite loop as a result of CMake touching one of its input files,
causing the build to restart.
- Does not deal with certain file layouts involving symlinks.

Thanks,
--
Peter

[Richard Geary]

Hi Peter,

This looks interesting, a daemonized fs-watching ninja has been mentioned on this list a long time ago. I see your Watcher class provides an interface to provide FS event updates - one alternative for this for nfs which has no inotify, and provide the fs events with a socket.

You may have read it already, but there's a good write-up of the difficulties of implementing a recursive inotify here : http://lwn.net/Articles/605128/

Also, you may want to warn if the system runs out of inotify resources - our default system setup here had a low inotify limit.

Best,

Richard

--
Peter

--
You received this message because you are subscribed to the Google Groups "ninja-build" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ninja-build...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Robert Iannucci]

Oh cool! :D. I don't have a lot of helpful things to say, but I'd love this :)

[Evan Martin]

Super cool!

Do you have any thoughts on this vs using some bash loop like "while inotifywait ..; do ninja ...; done" ?  (I've used this pattern for tiny projects in the past for a continuous build mode.)

--
Peter

[Peter Collingbourne]

There are at least three disadvantages of that approach that I can think of:

1. It is prone to races. Consider the case where a compiler has read a source
file foo.c and is halfway through compiling it when foo.c is overwritten.
Then foo.o will appear to be newer than foo.c but will not be up to
date. Restarting the build immediately on file changes avoids this problem.

2. It wastes time if a file is changed during a build; you would probably
want to see the results of those changes as soon as possible instead
of waiting for the current build to terminate (with results you probably
don't care about any more). Again, this problem can be solved by restarting
the build.

3. You need to have some way of getting the list of file names out. This can be
tricky from a scripting perspective, and it might exceed command line
length limits. The list may also change over time in reaction to changes
to depfiles or generator inputs, and ideally you would want those changes
to be loaded in as soon as possible. (Or you could use inotifywait's
recursive mode, but that won't necessarily work for every project.)

--
Peter

[Peter Collingbourne]

On Mon, Aug 11, 2014 at 06:01:49PM -0400, Richard Geary wrote:
> Hi Peter,
>
> This looks interesting, a daemonized fs-watching ninja has been mentioned
> on this list a long time ago. I see your Watcher class provides an
> interface to provide FS event updates - one alternative for this for nfs
> which has no inotify, and provide the fs events with a socket.

Other obvious alternatives include watchers for other operating systems
and a mock watcher for tests.

> You may have read it already, but there's a good write-up of the
> difficulties of implementing a recursive inotify here :
> http://lwn.net/Articles/605128/

I hadn't read that article. The problem we have to solve is slightly different
to the one in the article, as we don't need to monitor every path in a tree
recursively, just the ones that are mentioned in the manifest file. The
design is intended to avoid race conditions by (e.g.) creating watches on
directories before inspecting them, as mentioned in the article. I have yet
to implement queue overflows, though, and I don't think I need to handle
renames beyond treating them as a delete/create pair.

> Also, you may want to warn if the system runs out of inotify resources -
> our default system setup here had a low inotify limit.

Right, I'll need to add more robust error handling.

Peter

--
Peter