Re: GMAKE 3.81 vs GMAKE 4.2

[nikhil jain]

Any comments?

On Wed, 4 Dec 2019, 18:14 nikhil jain, <address@hidden> wrote:

> Just for information.
>
> Issue is not reproduced when replacing stat with safe_stat() which double
> checks the file for stale handle.
>
> thanks
> Nikhil
>
> On Wed, Dec 4, 2019 at 12:51 PM nikhil jain <address@hidden>
> wrote:
>
>> Thanks for all the help. There was another script which was causing issue
>> with the signal. I am able to catch the signal in make.
>>
>> I successfully implemented the remote execution feature in make 3.81
>>
>> I need some help.
>> My rules execute on different hosts on NFSi submit a job from host 1.
>>
>> A rule which executes in host A creates a .o file.
>> Once it is done, make checks for the next rule which is dependent on this
>> one.
>>
>> But on the submission host while making the dependency graph again, it
>> sees that the .o timestamp is not newer which means it is still reading the
>> old .o file.
>>
>> So it doesn't build the target.
>> I know this is normal as it is on NFS so latency is there.
>>
>> But can I do something from make side to cover this latency? I tried
>> putting sleep. It works but we don't know what is the optimal sleep value.
>>
>> Also, sleep slows down the complete build time.
>>
>> I see a function safe_stat() and now it is convert d to just stat()
>>
>> What was the difference actually ? Why we moved from safe_stat() to stat?
>>
>> Is this related to the issue I am facing.
>>
>> Please provide any help or suggestions from the make side by which I can
>> remove this issue.
>>
>> FYI, I had tried in lsmake from IBM but I was not able to replicate this
>> scenario.
>>
>> Is there something like NFS flushing which I can do from make side ???
>>
>> Urgent help needed. Blocking many production releases.
>>
>> Also, if I touch a single file and try to run it, I am able to reproduce
>> the issue.
>>
>> But if I touch multiple files and then run the build, I don't see issue
>> as some file would be updated and seen over NFS on the submission host.
>>
>> Let me know any pointers to how I can overcome this behaviour.
>>
>> Thanks
>> Nikhil
>>
>>
>> On Tue, 22 Oct 2019, 00:04 Paul Smith, <address@hidden> wrote:
>>
>>> On Mon, 2019-10-21 at 22:47 +0530, nikhil jain wrote:
>>> > see this how it works in makefile. It is part of the target -
>>> >
>>> > bash-4.1$ cat Makefile
>>> > a1:
>>> >         trap 'USER_INT=1; /bin/echo "terminating, please wait...."'
>>> INT; \
>>> >         sleep 100
>>> >
>>> > bash-4.1$ make
>>> > trap 'USER_INT=1; /bin/echo "terminating, please wait...."' INT; \
>>> >         sleep 100
>>> > ^Cterminating, please wait....
>>> > make: *** [a1] Error 130
>>> >
>>> > see this ? When make was executing sleep 100 , I gave ctrl+c and got
>>> > my message " terminating, please wait". It did not go to
>>> > fatal_error_signal at all.
>>>
>>> It DID go to fatal_error_signal().  Why do you think it didn't?  Just
>>> because your trap was called doesn't mean that make didn't catch the
>>> signal.
>>>
>>>