]> Git Repo - buildroot-mgba.git/commit - Makefile
Makefile: fix build when $(O) ends in _defconfig
authorYann E. MORIN <[email protected]>
Sun, 22 Jan 2023 09:09:47 +0000 (10:09 +0100)
committerYann E. MORIN <[email protected]>
Mon, 6 Feb 2023 13:21:42 +0000 (14:21 +0100)
commit5bd2cafc326141eede4f917069ed21b6d38f88c2
tree11280c16cd039a124799389b62b1143fb360a327
parent0b42512f2f6c3957637d698de20c3930dfcd85e3
Makefile: fix build when $(O) ends in _defconfig

Commit e6195c53041f (Makefile: fix use of many br2-external trees) fixed
a slowdown with many br2-external trees. In doing so, it changed the
type of the %_defconfig rule: the stem is no longer present in the
prerequisites, so it changes from a pattern rule to an implicit pattern
rule [0].

It is not unusual to name the build directory after the defconfig that
is being built, so we may end up with a build directory named
meh_defconfig. Before e6195c53041f, the pattern rule would not match
[1], but now it does, which causes somewhat-cryptic build failures:

    Makefile:1015: *** "Can't find /some/path/meh_defconfig".  Stop.

The issue is that we have this set of rules and assignments (elided and
reordered for legibility):

    all: world
    world: target-post-image
    target-post-image: staging-finalize
    staging-finalize: $(STAGING_DIR_SYMLINK)
    $(STAGING_DIR_SYMLINK): | $(BASE_DIR)
    BASE_DIR := $(CANONICAL_O)
    CANONICAL_O := $(shell mkdir -p $(O) >/dev/null 2>&1)$(realpath $(O))

So, there is a rule that (eventually) has a dependency on $(O), but we
have no rule that provides it explicitly, so the %_defconfig rule kicks
in, with the stem as "/some/path/meh". When the loop searches all the
".../configs/" directories for a file named ".../configs/%_defconfig",
it actually looks for a file named ".../configs//some/path/meh_defconfig"
and that indeed never matches anything.

The solution is to provide an actual rule for $(BASE_DIR), so that the
implicit rule does not kick in.

[0] Terminology and behaviour in make is hard, so the terms we used here
    may be wrong or incorrectly used, and/or the explanations for the
    behaviour be wrong or incomplete... Still, the reasoning stands, and
    the root cause is the removal of the stem in the RHS of the rule
    (adding one back does fix the issue).

[1] not sure how the prerequisite was solved  before e6195c53041f,
    though...

Fixes: e6195c53041f
Reported-by: Romain Naour <[email protected]>
Signed-off-by: Yann E. MORIN <[email protected]>
Cc: Nevo Hed <[email protected]>
Cc: Peter Korsgaard <[email protected]>
Tested-by: Sebastian Weyer <[email protected]>
Signed-off-by: Yann E. MORIN <[email protected]>
Makefile
This page took 0.032716 seconds and 4 git commands to generate.