Re: [XEN PATCH v7 20/51] build: avoid re-executing the main Makefile by introducing build.mk

[Jan Beulich <jbeulich@xxxxxxxx>]

On 11.10.2021 16:58, Anthony PERARD wrote:
> On Mon, Oct 11, 2021 at 12:56:54PM +0200, Jan Beulich wrote:
>> On 24.08.2021 12:50, Anthony PERARD wrote:
>>> Currently, the xen/Makefile is re-parsed several times: once to start
>>> the build process, and several more time with Rules.mk including it.
>>> This makes it difficult to reason with a Makefile used for several
>>> purpose, and it actually slow down the build process.
>>
>> I'm struggling some with what you want to express here. What does
>> "to reason" refer to?
> 
> I guess "to reason with something" isn't an expression. I mean that the
> main Makefile is difficult to work with as it setup the build process
> for the rest of the build. And it is difficult to understand what is
> happening when it recursed into itself, and thus possibly re-executing
> part of the build process setup.
> 
>>> So this patch introduce "build.mk" which Rules.mk will use when
>>> present instead of the "Makefile" of a directory. (Linux's Kbuild
>>> named that file "Kbuild".)
>>>
>>> We have a few targets to move to "build.mk" identified by them been
>>> build via "make -f Rules.mk" without changing directory.
>>>
>>> As for the main targets like "build", we can have them depends on
>>> there underscore-prefix targets like "_build" without having to use
>>> "Rules.mk" while still retaining the check for unsupported
>>> architecture. (Those main rules are changed to be single-colon as
>>> there should only be a single recipe for them.)
>>>
>>> With nearly everything needed to move to "build.mk" moved, there is a
>>> single dependency left from "Rules.mk": $(TARGET), which is moved to
>>> the main Makefile.
>>
>> I'm having trouble identifying what this describes. Searching for
>> $(TARGET) in the patch doesn't yield any obvious match. Thinking
>> about it, do you perhaps mean the setting of that variable? Is
>> moving that guaranteed to not leave the variable undefined? Or in
>> other words is there no scenario at all where xen/Makefile might
>> get bypassed? (Aiui building an individual .o, .i, or .s would
>> continue to be fine, but it feels like something along these lines
>> might get broken.)
> 
> I mean that "xen/Rules.mk" will never "include" "xen/Makefile" after
> this patch, but the variable "TARGET" is only set in "xen/Rules.mk". But
> "xen/Makefile" still needs "TARGET" to be set so I moved the assignment
> of the variable from "xen/Rules.mk" into "xen/Makefile".

Okay, thanks, this confirms the understanding I had developed; maybe
you try to reword this some. What your reply doesn't address is my
question, though.

Jan