Re: GMAKE 3.81 vs GMAKE 4.2

[nikhil jain]

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.
>>
>>