[Top][All Lists]

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

Re: automake less verbose (iter 3)

From: Ralf Wildenhues
Subject: Re: automake less verbose (iter 3)
Date: Sun, 8 Mar 2009 10:01:22 +0100
User-agent: Mutt/1.5.18 (2008-05-17)

Hi Jan,

while reviewing the threads about this topic, I found this:

* Jan Engelhardt wrote on Wed, Dec 24, 2008 at 11:47:36PM CET:
> On Monday 2008-12-22 22:28, Ralf Wildenhues wrote:
> >[ from <> ]

> >I haven't found another way yet.  If we can't find one, then your choice
> >of $(var1$(var2)) is certainly better than nothing, in combination with
> >(1).

(which is what is in the current branch)

> I seem to remember that configure produces non-portable Makefiles
> anyway, so (1) should be ok; specifically, running `configure` on
> Linux and then issuing `make` on NetBSD, or vice versa, got me into
> shell syntax issues or something in that direction.

Well, no.  You cannot run configure on one system and expect the
produced makefiles and headers to work on another system.  That is
one fundamental aspect of autotools: the tarball is portable, then
you go and create a system-specific configuration by running configure.
That's one reason why VPATH builds are so helpful: you can use several
build trees, one per system, off a single source tree.

> >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?


> >  (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 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 files by
quite a bit.  This is important, when some files end up being in the MB


reply via email to

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