[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: automake less verbose (iter 3)
From: |
Jan Engelhardt |
Subject: |
Re: automake less verbose (iter 3) |
Date: |
Sun, 8 Mar 2009 16:02:06 +0100 (CET) |
User-agent: |
Alpine 2.00 (LSU 1167 2008-08-23) |
On Sunday 2009-03-08 10:01, Ralf Wildenhues wrote:
>
>> >Another minor issue I don't quite like yet: before this change,
>> >the code was quite carefully laid out to be performant in the
>> >generic fastdep case: GNU make can avoid spawning a shell for
>> >a command, when the command line to be executed can be shown
>> >to be free of shell special variables.
>>
>> Including ||, ``, \ and all those meta characters?
>
>Yes.
But if the presence of \ causes invocation of the shell already,
then adding || `` or \ myself (as in the original patches)
won't have a big impact because there are already lots of ` and \
in the rules due to automake/libtool rules from am/*.
>> > (For precise heuristics
>> >see the GNU make sources.) Breaking this means one more shell
>> >fork per source file.
>
>> Well the question is whether this does happen, because %VERBOSE%
>> just adds
>> @echo " CC " $@;
>> and this can entirely be handled by make alone, if its heuristics
>> are good.
>
>Current GNU make will invoke the shell for this for two reasons: the
>semicolon, and the built-in 'echo'. And if make is going to invoke
>the shell anyway for the echo, then it is not much more expensive to
>pass it the whole line.
>
>[ extra newline in V=1 output with some compile2.am rules ]
>> >Not nice; however, I don't see a good way
>> >around this either, at least not in the silent case, and without
>> >introducing new newlines in the output in the non-silent case.
>>
>> Well newlines can easily be avoided by getting rid of all the
>> continuation lines within an if block and writing the full command
>> lines out on every line. Yes, redundancy, but it's what it takes.
>
>Yes but that has the downside of enlarging some Makefile.in files by
>quite a bit. This is important, when some files end up being in the MB
>range.
Perhaps postprocessing configure with a tool (that understands
shell syntax) that removes all unneeded whitespace.