[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: GNU make troubleshooting
From: |
Bruno Haible |
Subject: |
Re: GNU make troubleshooting |
Date: |
Mon, 17 Jul 2023 15:43:05 +0200 |
Dmitry Goncharov wrote:
> > I believe these two user goals are so different; they belong in different
> > chapters.
> ...
> In other words, i don't see a chapter on how to avoid big debug output
> without optimizing the makefile.
Wait a second. "How to avoid big debug output?" is not one of the primary
questions a user asks themselves. (It's merely a guideline that one should
consider while writing troubleshooting documentation.) The primary user
question is "Which rules would be executed, and why?"
Another question, "What if a file was new?" can be answered through the '-W'
option, without producing big debug output.
Both of these questions have in common that they require Make to print
only the rules or actions that Make is considering. They don't require
Make to print the reasons why it is *not* considering this and that chain
of built-in rules.
> > > > Can the addition of 'makefile::;' be replaced by a make option or
> > > > by some (sed-based?) postprocessing?
> > >
> > > There is no option.
> > > You can grep away most of the matching lines with 'grep -v makefile'.
> >
> > Then it's useful to present this as a filter in the troubleshooting
> > section.
>
> i'd rather have the manual to teach how to modify the makefile to
> relieve make from doing redundant work.
> i am puzzled why you prefer working around with options and filters.
> Are you thinking about a scenario where you cannot modify the makefile?
No, I'm following the common engineering practice "analyze, then remedy".
"Analyze" means understanding what a Makefile will do in a certain situation,
and why. "Remedy" means to change the Makefile, based on that understanding.
If, during the analysis phase, the engineer modifies the Makefile, there
is a high chance that they will get to wrong conclusions and thus make
wrong changes.
A related engineering practice is "when experimenting, change only one
variable at a time". Because if they change two variables at once and get
and improvement, they won't know which variable change is responsible for it.
> Another approach for the case when you cannot modify the makefile is this
>
> $ cat makefile
> all: hello
> $ make -nd |wc
> 1334 7530 63382
> $ make -E $'.DEFAULT_GOAL:=all\nmakefile::;' -nd |wc
> 732 4117 32947
This is better for text under the topic "Understanding a Makefile's action".
Thanks.
Bruno
- Re: GNU make troubleshooting, (continued)
Re: GNU make troubleshooting, Eli Zaretskii, 2023/07/10
Re: GNU make troubleshooting, Dmitry Goncharov, 2023/07/15
Re: MAKEFLAGS=-r, Bruno Haible, 2023/07/17
Re: MAKEFLAGS=-r, David Boyce, 2023/07/17
Re: MAKEFLAGS=-r, Bruno Haible, 2023/07/17
Re: MAKEFLAGS=-r, David Boyce, 2023/07/17
Re: MAKEFLAGS=-r, Bruno Haible, 2023/07/17
Re: MAKEFLAGS=-r, Dmitry Goncharov, 2023/07/18
Re: MAKEFLAGS=-r, Paul Smith, 2023/07/17
Re: disabling the built-in rules, Bruno Haible, 2023/07/17
Re: disabling the built-in rules, Paul Smith, 2023/07/17
Re: disabling the built-in rules, Bruno Haible, 2023/07/17