Re: GNU Make 4.2 Query

[nikhil jain]

Hi,

Thanks for your reply.

1) Yes retrying every command ONLY when it fails which is less than 1% of
the case, less than .5% of the cases. It is very very rare.

The paths are visible to all the hosts and there are no clock issues. Even
if there are clock issues or path issues, I can debug that and run another
build and remove that host from the list, That is something I can check.
That has nothing to do with retry logic.

Sorry, R&D wont change their implementation. I could not force them.

Neither Target not Pre-requisites are local objects. They are available on
all the hosts. But, as I said, sometimes (very very rarely), the task can
fail because the host is loaded and sync of NFS across hosts take more than
expected time.

I can't build a system keeping only the SUCCESS cases in mind.
 The retry is needed even if there is no remote execution host feature.
Even on the same host if the build fails, then what to do ? ?? Run the
build from scratch ? That is a waste of time and resource.

On Mon, Sep 2, 2019 at 11:53 AM Kaz Kylheku (gmake) <
address@hidden> wrote:

> On 2019-09-01 23:04, nikhil jain wrote:
> > Hi,
> >
> > Thanks for your reply.
> >
> > Actually, this is not possible in my case. The builds are run by the
> > R&D teams who are using legacy GNUmakefile. So, I can't force them to
> > change their way and there are around 10k+ commands in a makefile.
> > I would rather implement the retry feature in GMAKE like I had
> > implemented the Remote Execution feature. Thanks for your concern.
>
> Oh you want to put in a feature for GLOBALLY retrying every command
> in every recipe?
>
> That's just a non-starter; I can't imagine such a thing would ever
> be upstreamed.
>
> One reason I suspect it would not be upstreamed is that the behavior can
> be
> achieved with an alternative shell interpreter, which can be specified
> via the SHELL variable. Whatever you put into the SHELL is the
> interpreter
> used for all recipe commands. Look more into it in the doc.
>
> If your R&D team would allow you to add just one line to the
> legacy GNU Makefile to assign the SHELL variable, you can assign that
> to a shell wrapper program which performs command re-trying.
>
>
> > Just a point - I think a retry feature is really needed in GMAKE.
> > it is a very useful for everybody.
> > Remote execution , I understand can be implementation specific so you
> > guys left it as a stub. But, retry SHOULD be part of GMAKE.
>
> Remote execution /per se/ should also be doable via SHELL. But, how
> would
> it work if the target and prerequisites are local objects. The purpose
> of a recipe is to update a target when it's missing or older than at
> least
> one of the prerequisites.
>
> If you have a common namespace via NFS mounts or whatever, it can make
> sense. Say that /path/to/foo/bar.c is visible on all hosts. You can
> check
> locally whether /path/to/foo/bar.o needs updating, but run the compiler
> on some remote host.
>
> You will likely get "clock skew" issues, due to the remote host setting
> the modification time stamp of the updated target, using a clock that is
> not exactly synchronized with the local machine that's actually
> comparing
> timestamps.
>
>