Re: [bug #64288] The flag --no-print-directory becomes effective too early

[Paul Smith]

Just to note you can still post comments to bugs in Savannah, and they
will be sent out to the list like any other bug, even if they're
closed.  But discussing on the mailing list directly is fine too!

On Fri, 2023-06-09 at 23:46 +0900, Masahiro Yamada wrote:
> On Fri, Jun 9, 2023 at 9:39 PM Paul D. Smith
> > This behavior is intentional: setting MAKEFLAGS as a make variable
> > assignment modifies the behavior of the currently-running make.  If
> > users want to disable printing directories for the current makefile
> > they can do so by setting the MAKEFLAGS variable.
> 
> I argue this change is not sensible.
> 
> It is strange to have the sub-make control the "Entering directory
> sub".
> 
> Child makefiles do not know how the parent has invoked it.
> Only the parent makefile knows whether it is changing the working
> directory or not.

You seem to slightly misinterpret this option.

The option is not, "show a message when we switch to a subdirectory and
invoke make".

The option is, "show a message containing the current directory when a
child make starts".  Or technically, "before a child make prints any
other output" as it's implemented.

In other words, the message is printed by the child make, showing its
current directory, REGARDLESS of whether the child make is in a
different directory or the same directory.

> "Entering directory ..." is just annoying because it is staying at
> the same working directory.

It has never been the case that make would avoid printing the message
only when it changed directories.

In any event, if that's what you want it's clearly impossible to
implement that from within the child makefile because it has no idea
whether the parent make changed directories or not.  Only the parent
make can know that, so only the parent make can add (or not) that
option.

> Linux kernel build system uses both styles.
> In most cases, Kbuild uses the "-f <sub-dir>/Makefile" and suppresses
> the "Entering ...".
> 
> Kbuild sometimes needs to change the working directory, in this case,
> "Entering ..." is mandatory because IDEs are tracking the working
> directories.

My opinion is that it's not worthwhile to try to suppress the "useless"
messages if you're using an IDE which requires them.  IDEs don't care
about extra messages and they don't hurt anything.

If a user doesn't like them and thinks they look messy when they invoke
make from the command line / outside an IDE, they can simply invoke the
top-level make with the --no-print-directory option themselves, or add
it to their GNUMAKEFLAGS environment variable or whatever.

So my advice, for what it's worth, is just to remove the special
handling of --no-print-directory and let print-directory be in effect
everywhere by default, so IDEs work, and leave it up to individuals to
turn it off on their own if they don't like to see it.

In any event, adding this to MAKEFLAGS is problematic because it not
only takes effect for the current makefile but also all sub-makes that
are invoked, and all their sub-makes, etc.  Also what if you set this
value, and some of your sub-makes change directories and some do not?

Your use-case appears limited to exactly how the kbuild system works,
where you happen to know that all sub-makes of a given makefile (a)
never change directories before invoking sub-make AND (b) either none
of its sub-makes invoke sub-makes of their own, or at least none of
those sub-makes ever change directories before invoking more sub-makes.

> Now, Kbuild is broken, so I need to fix it.
> 
> https://lore.kernel.org/linux-
> kbuild/CAK7LNAS1=RtTTYk=+q2YsGmMNQ6EwhAx=STEj+cXzWkNzT6nWQ@mail.gmail
> .com/T/#m7757ec3b62dd541014fcfa1cd6b84432222e4286
> 
> 
> You could still argue to add --no-print-directory to every place:
> 
>     .PHONY: sub
>     sub:
>            $(MAKE) --no-print-directory -f sub/Makefile
> 
> But, there are a lot of locations invoking the submakes.
> Do I need to add --no-print-directory to all of them?

If you want to continue to keep a distinction between sub-makes that
change directories and sub-makes that don't change directories, there's
no reliable way to get around writing the recipes differently.  Only
the recipes know which kind of sub-make is being invoked.

One way to do it would be to have two different variables to invoke
make, like:

   HERE := --no-print-directory
   SUB := --print-directory

then:

   thisdir: ; $(MAKE) $(HERE) -f sub/Makefile
   subdir: ; $(MAKE) $(SUB) -C sub

Or alternatively you can just create new variables for make itself, but
if you do this you must remember to prefix recipes with "+":

   MAKEHERE = $(MAKE) --no-print-directory
   MAKESUB = $(MAKE) --print-directory

   thisdir: ; +$(MAKEHERE) -f sub/Makefile
   subdir: ; +$(MAKESUB) -C sub

(you can add the "+" into the variable instead but then you can't use
it inside a recipe; it has to always be the first word in the recipe
line.)

> Previously, I was able to do
> "MAKEFLAGS += --no-print-directory" in a single place,
> but it is now impossible.

This is actually a side-effect of the change that has MAKEFLAGS
interpreted as soon as it's set, rather than waiting until much later.
That change adds a lot of new capabilities, but while previously you
used to be able to set MAKEFLAGS and have it only affect child makes,
now that's not the case anymore.

I suppose we could add a new variable that you could set that would
automatically be included in sub-make invocations but not interpreted
by the current make instance, without having to add it explicitly to
the sub-make recipe.  Obviously any new feature won't help you solve
your immediate problem.