automake-patches
[Top][All Lists]
Advanced

[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.




reply via email to

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