Re: Advanced Auto-Dependency Generation and Parallel Execution

[Garrett Cooper]

On Tue, Dec 2, 2008 at 11:59 AM, Garrett Cooper <address@hidden> wrote:
> On Mon, Dec 1, 2008 at 10:06 PM, Paul Smith <address@hidden> wrote:
>> On Mon, 2008-12-01 at 18:51 -0800, Garrett Cooper wrote:
>>> Another issue is ncurses and how it does it's echo'ing (see the
>>> following line from progs/Makefile.in):
>>>
>>> transform.h :
>>>         echo "#define PROG_CAPTOINFO \"$(define_captoinfo)\"" >$@
>>>         echo "#define PROG_INFOTOCAP \"$(define_infotocap)\"" >>$@
>>>         echo "#define PROG_RESET     \"$(define_reset)\""     >>$@
>>>         echo "#define PROG_INIT      \"$(define_init)\""      >>$@
>>>
>>> Under certain conditions this fails (the bugs who reported the
>>> internal bug didn't have a clearcut means for reproducing the issue).
>>
>> I can't see any possible way that this could fail, unless maybe there
>> are multiple instances of make trying to create this same file.  I don't
>> accept the assertion that this is real-life race-condition-prone code.
>>
>> When this fails, what are the symptoms?  Is the transform.h file
>> corrupted somehow?  In what way?
>
> I believe that was the case yes, and the problem might have been NFS /
> latency related because we do a lot of our development on NFS shares
> with a large number of users, and overtaxed systems.
>
> If that's truly the case, this is more of a bi-product of an NFS level
> caching and ordering of messages issue.
>
> [OT]
> Still... if things are going to be rather static like that and not
> going to change across compiles, why not just generate the file once
> and leave it as-is?
> [/OT]
>
> -Garrett

Sorry -- forgot to mention the symptom. It was compile failures due to
atypical missing symbols.
-Garrett