Re: GNU Make 4.2 Query

[Kaz Kylheku (gmake)]

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.