[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:
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
- problems in Emacs with GL_GENERATE_STDINT>H, Paul Eggert, 2021/12/16
- Re: problems in Emacs with GL_GENERATE_STDINT_H, Bruno Haible, 2021/12/18
- Re: problems in Emacs with GL_GENERATE_STDINT_H, Paul Eggert, 2021/12/18
- Re: problems in Emacs with GL_GENERATE_STDINT_H, Bruno Haible, 2021/12/19
- Re: problems in Emacs with GL_GENERATE_STDINT_H, Paul Eggert, 2021/12/19
- Re: MKDIR_P invocations, Bruno Haible, 2021/12/20
- Re: MKDIR_P invocations, Paul Eggert, 2021/12/20
- Re: MKDIR_P invocations, Bruno Haible, 2021/12/21
- Re: makefile rules, Bruno Haible, 2021/12/21
- Re: makefile rules,
Paul Eggert <=
- Re: makefile rules, Jim Meyering, 2021/12/21
- Re: makefile rules, Paul Eggert, 2021/12/21
- Re: makefile rules, Jim Meyering, 2021/12/21
- Re: makefile rules, Paul Eggert, 2021/12/21
- Re: makefile rules, Jim Meyering, 2021/12/22
- Re: makefile rules, Bruno Haible, 2021/12/21
- Re: makefile rules, Bruno Haible, 2021/12/21
- Re: makefile rules, Paul Eggert, 2021/12/22
- Re: makefile rules, Paul Eggert, 2021/12/23
- Re: makefile rules, Bruno Haible, 2021/12/24