[Top][All Lists]

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

Re: makefile rules

From: Paul Eggert
Subject: Re: makefile rules
Date: Tue, 21 Dec 2021 11:36:19 -0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.3.1

On 12/21/21 01:41, Bruno Haible wrote:

The number of developers who know about 'echo', 'cat', and *simple* 'sed'
commands is far larger than the number of developers who know about
advanced 'sed' commands (with hold space etc.).

I'm not all that worried about this issue, as this stuff is boilerplate. (Most developers these days don't know sed either; times change....) That being said, the boilerplate is indeed error-prone and should be made easier. Done in the second draft of the patch, which is attached. It assumes we arrange for something like this in the Makefile:

   -e 1h \
   -e '1s,.*,/* DO NOT EDIT! GENERATED AUTOMATICALLY! *,w $@-t' \
   -e 1g
   -e 'w $@-t'

(and we can put comments near this explaining 'sed' to the uninitiated :-).

The old code prints "GEN alloca.h" before executing the commands;
the new code prints "GEN alloca.h" after most commands are done.

That's a bug in my patch's first draft, fixed in the second draft.

The bug was inspired by similar bugs in Gnulib's already-existing Makefile snippets, which as it happens yesterday I told another Emacs developer that I'd fix. I installed the second attached patch to fix the Gnulib issues.

That means, when the commands don't behave right (loop endlessly
or whatever) and the user interrupts them with Ctrl-C, he will have
no clue which rule was misbehaving.

Typically I use 'make V=1' or 'make --trace' or even 'strace -f make' to debug problems like that, and something like that is needed anyway regardless of where the AM_V_GEN appears in the recipe.

3) It suggests a coding style that only works when there are no shell
variable assignments in the command.

This is a plus, not a minus. If we omit the '&& \', a makefile developer doesn't have to worry earlier shell commands affecting the setup of the current command. The '&& \' is a signal to the developer, "Watch out: this recipe is tricky!" and when that signal is absent the developer can relax and concentrate on more important things.

Sometimes it's important to do shell assignments with side effects, and in those cases the '&& \' is needed and is a good signal to have. But it should be omitted when unnecessary.

Omitting the '&& \' also helps debugging. I use 'make V=1' without '&& \', I see each command individually just before it's executed, rather than the entire recipe being output all at once.

And it would let GNU make invoke rm, mkdir, sed, and mv
directly instead of via a subshell, which would be a minor efficiency plus.

Now, that's a micro-optimization in the bad sense of the word. It's like
rewriting C code such as
   x += 1;
because you know that you current compiler will generate faster code for the

It's not merely a micro-optimization; it can make debugging easier. I recently went through the exercise of using 'strace -f make' to debug a 'make' session that went awry. When it's easy to cut down on the number of fork+exec calls (as is the case here), it'll make these sessions easier.

The real fix should be to improve GNU make in such a way that it does not
make a difference whether one writes



        command1 && command2


        { command1 && command2; }

Although that might be a valid performance improvement, it's not the 'make' that we have, and anyway it doesn't address the clarity issues mentioned earlier.

(I suppose we should also omit that 'rm -f $@-t $@'; it shouldn't be

It can needed when people have done something like
   $ make
   $ sudo make check

If you run 'make' sometimes as one user and sometimes as another, you can have problems like that no matter what. We don't put 'rm -f $@' at the start of every other makefile recipe to work around those problems; why are these recipes special?

On the slow build hosts that I use, the entire set of commands for
creating .h files is faster than compiling a single .c file

I'm well aware that other things take much more time, 'configure' being the worst offender. That being said, improving those other things is something I don't have the time to do right now, whereas this improvement should be easy. And anyway performance is not the main motivation here.

Attachment: alloca1.diff
Description: Text Data

Attachment: 0001-Move-AM_V_GEN-to-recipe-start.patch
Description: Text Data

reply via email to

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