My company uses a third-party patch set which enhances GNU make for distributed builds. There are many approaches to distributing builds and this is just one but I believe the problem described here is general to all distributed build models.
Distributed builds, naturally, must occur in NFS which has many configurables. In most configurations it does pretty aggressive caching in search of best performance. This can lead to situations in which recipe A has created target X on host H1 but when a dependent recipe B runs on host H2 and attempts to read from X the data, or more commonly the file itself, hasn't arrived on H2 yet. This can cause distributed builds to be unreliable even when conceptually (in terms of DAG and input files) they're entirely correct. One solution is to mount with the 'sync' option. However, this is a big performance and bandwidth hit and most organizations don't want to do it. Besides, in the case of distributed make we don't necessarily need everything to be synced/flushed at all times; in almost all cases it's only the file represented by $@ that matters (when it becomes part of $? downstream). So the ideal is to be able to NFS-sync only updates to $@, whose value is of course ephemeral. According to Google you can force a flush of the NFS filehandle cache (to ensure host H2 knows about a file newly created on H1) for a given directory by doing an opendir()/closedir() sequence on H1 after the file is created, and experimentation seems to bear this out. Similarly, the _contents_ of a recently written file can supposedly be flushed to NFS by locking and unlocking it with fcntl() though we haven't tested (or needed) this option yet. The sticking point in all of this is knowing what file and directory to work with, i.e. the value of $@. Does anyone know make internals well enough to tell me where and how to get access to $@ just after the recipe has finished? I'm thinking of experimenting with an enhancement locally but could submit it as a new feature if desired. Thanks, David Boyce
_______________________________________________ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
