help-make
[Top][All Lists]
Advanced

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

Re: GNU Make 4.2 Query


From: nikhil jain
Subject: Re: GNU Make 4.2 Query
Date: Mon, 2 Sep 2019 20:48:08 +0530

Something sounds interesting  from your message.

What is this .ONESHELL ?

If I have -

All:
    mkdir dir
    cd dir


So currently in my remote execution design these 2 commands execute on
different host.

So, does ONESHELL will make these 2 commands on the same host ?

Please reply as soon as you can. This will solve few of my purposes and
make my builds faster.

Thanks
Waiting for reply.

On Mon, 2 Sep 2019, 18:08 Paul Smith, <address@hidden> wrote:

> On Sun, 2019-09-01 at 23:23 -0700, Kaz Kylheku (gmake) wrote:
> > 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.
>
> You don't have to add any lines to the makefile.  You can reset SHELL
> on the command line, just like any other make variable:
>
>     make SHELL=/my/special/sh
>
> You can even override it only for specific targets using the --eval
> command line option:
>
>     make --eval 'somerule: SHELL := /my/special/sh'
>
> Or, you can add '-f mymakefile.mk -f Makefile' options to the command
> line to force reading of a personal makefile before the standard
> makefile.
>
> Clearly you can modify the command line, otherwise adding new options
> to control a putative retry on error option would not be possible.
>
> As for your NFS issue, another option would be to enable the .ONESHELL
> feature available in newer versions of GNU make: that will ensure that
> all lines in a recipe are invoked in a single shell, which means that
> they should all be invoked on the same remote host.  This can also be
> done from the command line, as above.  If your recipes are written well
> it should Just Work.  If they aren't, and you can't fix them, then
> obviously this solution won't work for you.
>
> Regarding changes to set re-invocation on failure, at this time I don't
> believe it's something I'd be willing to add to GNU make directly,
> especially not an option that simply retries every failed job.  This is
> almost never useful (why would you want to retry a compile, or link, or
> similar?  It will always just fail again, take longer, and generate
> confusing duplicate output--at best).
>
> The right answer for this problem is to modify the makefile to properly
> retry those specific rules which need it.
>
> I commiserate with you that your environment is static and you're not
> permitted to modify it, however adding new specialized capabilities to
> GNU make so that makefiles don't have to be modified isn't a design
> philosophy I want to adopt.
>
>


reply via email to

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