On 15.02.2024 18:23, Roger Pau Monné wrote: > On Thu, Feb 15, 2024 at 05:22:00PM +0100, Jan Beulich wrote: >> On 15.02.2024 17:08, Roger Pau Monné wrote: >>> On Thu, Feb 15, 2024 at 02:02:41PM +0100, Jan Beulich wrote: >>>> --- a/xen/Rules.mk >>>> +++ b/xen/Rules.mk >>>> @@ -15,7 +15,11 @@ srcdir := $(srctree)/$(src) >>>> PHONY := __build >>>> __build: >>>> >>>> --include $(objtree)/include/config/auto.conf >>>> +ifneq ($(obj),tools) >>>> +ifneq ($(obj),tools/kconfig) >>>> +include $(objtree)/include/config/auto.conf >>>> +endif >>>> +endif >>> >>> Trying to understand this, I assume it's to avoid an infinite >>> dependency loop that generating include/config/auto.conf requires some >>> tools that are build using xen/Rules.mk? >> >> The file has dependencies only in xen/Makefile. This is about the >> file simply not being there when initially building. Perhaps the >> patch description helps that I've written in the meantime: >> >> "Because of using "-include", failure to (re)build auto.conf (with >> auto.conf.cmd produced as a secondary target) won't stop make from >> continuing the build. Arrange for it being possible to drop the - from >> Rules.mk, requiring that the include be skipped for tools-only targets. > > Wouldn't it be more reliable if we skipped the include for any paths > in $(obj) that start with 'tools', rather than hardcoding 'tools' and > 'tools/kconfig'?
I was first meaning to do so, but the expression would end up more complex than I'd like (for it needing to be an exact match of "tools" and a prefix match of "tools/"). Thinking of it, ifneq ($(obj),tools) ifneq ($(patsubst tools/%,$(obj)),) might do (and not be as complex as I first thought, when intending to put all in a single "if"). Yet then it's not entirely impossible that we might gain a build tool which is actually to be built after .config was (re)generated, i.e. in the know of the target configuration. Thoughts? Jan
