help-make
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GMAKE 3.81 vs GMAKE 4.2


From: nikhil jain
Subject: Re: GMAKE 3.81 vs GMAKE 4.2
Date: Wed, 4 Dec 2019 12:51:59 +0530

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]