[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#13349: Re-execute with the "correct" make implementation
From: |
Stefano Lattarini |
Subject: |
bug#13349: Re-execute with the "correct" make implementation |
Date: |
Fri, 04 Jan 2013 01:01:36 +0100 |
On 01/04/2013 12:35 AM, Bob Friesenhahn wrote:
> On Fri, 4 Jan 2013, Stefano Lattarini wrote:
>
>> On 01/03/2013 11:53 PM, Nick Bowler wrote:
>>> On 2013-01-03 23:05 +0100, Stefano Lattarini wrote:
>>>>
>>>> TARGETS = all check clean distclean dist distcheck install uninstall
>>>> .PHONY: $(TARGETS)
>>>> $(TARGETS): ; @gmake $(AM_MAKEFLAGS) $@
>>>
>>> Unfortunately, this kind of wrapper doesn't work particularly well. If
>>> the user runs something similar to:
>>>
>>> make -j2 all install
>>>
>>> then the wrapper makefile will happily fork off two independent make
>>> instances in parallel: one running "gmake all" and one running "gmake
>>> install". The result will probably be catastrophic.
>>>
>> Sigh, so very true. Adding ".NOTPARALLEL:" could fix this issue though.
>> Assuming that it is portable enough ...
>>
>> At any case, the wrapper would be just a convenience for the most
>> common cases, like:
>>
>> ./configure && make -j4 check && make install
>>
>> It doesn't have to work in all (or even most) scenarios.
>
> This problem (use of wrong 'make') does not impact Automake-NG at
> all and it does not seem wise to create a complex solution for a
> problem which is seldom encountered and typically benign.
>
I agree (but then, I'm biased, because I'd be the one who would have to
try to implement such a complex solution ;-)
But I think it's a fact that a simple "low-tech" solution like encouraging
developers who require GNU make (through Automake-Ng or otherwise) to use
the "GNUmakefile" name for their makefiles would probably give us 90% of
the benefits with 1% of the work.
Regards,
Stefano
- bug#13349: [IMPORTANT] Could we just assuming support for make recursive variable expansion unconditionally?, (continued)
- bug#13349: [IMPORTANT] Could we just assuming support for make recursive variable expansion unconditionally?, Bob Friesenhahn, 2013/01/03
- bug#13349: [IMPORTANT] Could we just assuming support for make recursive variable expansion unconditionally?, Eric Blake, 2013/01/03
- bug#13349: [IMPORTANT] Could we just assuming support for make recursive variable expansion unconditionally?, Stefano Lattarini, 2013/01/03
- bug#13349: [IMPORTANT] Could we just assuming support for make recursive variable expansion unconditionally?, Eric Blake, 2013/01/03
- bug#13349: Re-execute with the "correct" make implementation, Stefano Lattarini, 2013/01/03
- bug#13349: Re-execute with the "correct" make implementation, Eric Blake, 2013/01/03
- bug#13349: Re-execute with the "correct" make implementation, Stefano Lattarini, 2013/01/03
- bug#13349: Re-execute with the "correct" make implementation, Nick Bowler, 2013/01/03
- bug#13349: Re-execute with the "correct" make implementation, Stefano Lattarini, 2013/01/03
- bug#13349: Re-execute with the "correct" make implementation, Bob Friesenhahn, 2013/01/03
- bug#13349: Re-execute with the "correct" make implementation,
Stefano Lattarini <=
- bug#13349: Re-execute with the "correct" make implementation, Eric Blake, 2013/01/03
- bug#13349: Re-execute with the "correct" make implementation, Stefano Lattarini, 2013/01/03
- bug#13349: Re-execute with the "correct" make implementation, Eric Blake, 2013/01/03
- bug#13349: Re-execute with the "correct" make implementation, Stefano Lattarini, 2013/01/03