Re: Problem with make

[David Kastrup]

David Kastrup <address@hidden> writes:

> "address@hidden" <address@hidden> 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