On Tue, Oct 29, 2013 at 4:12 PM, Jed Brown <[email protected]> wrote:
> Matthew Knepley <[email protected]> writes: > > I see fooling with dependencies as a good thing in general to simplify > > things, but having not > > much to do with what Jed wants. We can easily buffer till kingdom come. > > The only reason I don't want to buffer too long is so that we don't have > too much history going into the error message. > > One possible problem with buffering forever is that if the disk fills up > while configure is running, we won't be able to write configure.log to > report the error without first freeing up space (and since we might not > be the only process filling up the disk, even that isn't guaranteed to > work). I do not think this is an important corner case. > >> No locking, just commit the results atomically. That means write a > >> temporary file and rename it to replace the existing file. (Or checksum > >> and just delete the tmp file if they match, so that modification times > >> don't change.) > >> > > > > This is not good enough for the stubs. > > Just because sowing is extremely file-based or for a real reason? > Because you can end up with an incompatible mix of stubs. The build may crash even though the stub generation process will not. Matt -- What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead. -- Norbert Wiener
