[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.
>
>
- Re: GNU Make 4.2 Query, nikhil jain, 2019/09/01
- Re: GNU Make 4.2 Query, Kaz Kylheku (gmake), 2019/09/02
- Re: GNU Make 4.2 Query, nikhil jain, 2019/09/02
- Re: GNU Make 4.2 Query, Kaz Kylheku (gmake), 2019/09/02
- Re: GNU Make 4.2 Query, nikhil jain, 2019/09/02
- Re: GNU Make 4.2 Query, Paul Smith, 2019/09/02
- Re: GNU Make 4.2 Query,
nikhil jain <=
- Re: GNU Make 4.2 Query, Paul Smith, 2019/09/02
- Re: GNU Make 4.2 Query, nikhil jain, 2019/09/02
- Re: GNU Make 4.2 Query, David Boyce, 2019/09/02
- Re: GNU Make 4.2 Query, nikhil jain, 2019/09/02
- Re: GNU Make 4.2 Query, David Boyce, 2019/09/02
- Re: GNU Make 4.2 Query, nikhil jain, 2019/09/02
- Re: GNU Make 4.2 Query, nikhil jain, 2019/09/17
- Re: GNU Make 4.2 Query, Paul Smith, 2019/09/21
- Re: GNU Make 4.2 Query, nikhil jain, 2019/09/22