Re: makefile rules

[Paul Eggert]

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:

  SED_HEADER_BEGIN = -n \
   -e 1h \
   -e '1s,.*,/* DO NOT EDIT! GENERATED AUTOMATICALLY! *,w $@-t' \
   -e 1g
  SED_HEADER_END = \
   -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;
> to
>    x++;
> because you know that you current compiler will generate faster code for the
> latter.

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
>
> or
>
>         command1 && command2
>
> or
>
>         { 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
> > needed
>
> 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.

alloca1.diff
Description: Text Data

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