bug-make
[Top][All Lists]
Advanced

[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






reply via email to

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