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.