David Kastrup <d...@gnu.org> writes: > "pkx1...@gmail.com" <pkx1...@gmail.com> writes: > >> hello, >> >> On Wed, Sep 21, 2011 at 05:13:00PM +0100, Phil Holmes wrote: >>> On my fast build system, I can't currently get a successful make. >>> Abort changes, pull, clean build directory. The build ends with: >> ... >>> As you see, the problem is a missing AUTHORS.texi. The odd thing is >>> that on previous make runs, I get >> >> yep, happens about 10% of the time for me. Running "make" again >> fixes it. (almost always -- the chance of two failing runs is >> about 1%. That's happened twice to me that I can recall) >> - - - >> >> happens to me nearly every time i make. You get news.tely and >> authors.texi. Failing. Run make again and it's fine. Never had two on >> the trot like graham. >> >> I probably run make about 10 times a day at the moment, checking >> patches. I'm used to it and just assumed it was one of our build >> quirks. You'll see lots more on faster machines in my own personal >> experience. > > That points to either a problem with parallel make processes, or more > likely a time stamp resolution problem. When file modification dates > are only accessed with second resolution (because the info is not > available in the file system type, or the application does not use it) > and a process for updates is quite fast, an updated dependent file may > seem to have the same time stamp as its original.
Expounding on that theory and doing pattern matching: does the problem get better or worse when you replace the > in python/book_snippets.py:781: > os.stat (single)[stat.ST_MTIME]))): with >= ? It may have nothing whatsoever to do with your problem, but that's a reference to a modification time I can see in the code. And what file system do you have? fat32 does not support more than second resolution IIRC. -- David Kastrup _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
