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: Tue, 17 Dec 2019 20:44:53 +0530

Have to check with the older team mates if they have added safe_stat by
themselves. Thanks to them. It works for my case atleast.

No, I do not want to delete the object file before sending the target out.
That's not how make should work or I should make it work. It is not make
issue. It is issue with NFS stale mounts which seems to be resolved if we
open the file again according to NFS specs (mentioned in another email).

Anyways, I will check if I need some more of your help. Thanks anyways.

On Tue, Dec 17, 2019 at 8:12 PM Paul Smith <address@hidden> wrote:

> On Tue, 2019-12-17 at 13:17 +0530, nikhil jain wrote:
> > A rule was processed and then as soon as it ends, the next dependent rule
> > processed. It has to work on the object file generated by the first rule.
> > But the timestamp of the file was older so the next rule did not process.
> > I am on NFS.
>
> I completely understand the issue.
>
> > I assume that this is because we are doing an open and read operation in
> > safe_stat which might remove the stale old file handle and make can see a
> > newer updated file.
> >
> > Also, the comment mentioned in the misc.c in the code you can see it has
> > to be related with NFS caching -
> >
> >     /* For safety's sake, read something to make sure NFS attribute cache
> >  *      * is updated
> >  *           */
>
> I have no idea where you've found this code.  This code does not exist in
> GNU make and, as far as I can tell from Git, has _never_ existed in GNU
> make.  I've searched the entire history back to 1988 and the term "NFS
> attribute" has never appeared anywhere in the GNU make source.
>
> Also, the implementation of safe_stat from the early 1990's has nothing to
> do with opening or reading: this is the implementation:
>
> commit 710e8e6f6f8c43e68bc4ee067bf7c9e37ca1f4e6
> Author: Roland McGrath <address@hidden>
> Date:   1994-07-04 21:46:58 +0000
>
>     (safe_stat): New function, EINTR-safe wrapper around stat.
>
> diff --git a/misc.c b/misc.c
> index 06be0b27..b9e76b9b 100644
> --- a/misc.c
> +++ b/misc.c
> @@ -716,3 +716,23 @@ get_path_max ()
>    return value;
>  }
>  #endif
> +^L
> +/* On some systems, stat can return EINTR.  */
> +
> +int
> +safe_stat (name, buf)
> +     char *name;
> +     struct stat *buf;
> +{
> +  int ret;
> +
> +#ifdef EINTR
> +  do
> +#endif
> +    ret = stat (name, buf);
> +#ifdef EINTR
> +  while (ret < 0 && errno == EINTR);
> +#endif
> +
> +  return  ret;
> +}
>
> It was removed again in Dec 1995 as I mentioned.  As you can see all it
> does is wrap the stat(2) call with a check for EINTR.
>
> > To answer your first question -
> >
> > YES, it works if i do a make clean (which deletes all the object files)
> > and the next make command will work. But for incremental build, It wont
> > work. I can reproduce the issue 8 out of 10 times with stat and 0 out of
> > 1000 times with safe_stat..
>
> Well I certainly wasn't suggesting you would run "make clean"!
>
> You've said you've implemented a facility that sends a compile command out
> to a different system to be run there, correct?  I was suggesting that you
> change this implementation so that on the local system BEFORE you send the
> command to another system to be invoked, you delete the specific target
> (and only that target) that will be built by that command.
>
> > Cant share exact code snippets as I am not allowed to.. but this is what
> > is happening...
>
> I'm not sure what you mean: if you've found implementations of safe_stat
> that was distributed with GNU make, somewhere, then those implementations
> are covered under the GPL.
>
>


reply via email to

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