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
