| Message ID | 20200410003917.22033-1-cotequeiroz@gmail.com |
|---|---|
| State | Rejected |
| Delegated to: | Petr Štetiar |
| Headers | show |
| Series | [OpenWrt-Devel] build: config: allow bool to select a module pkg | expand |
Eneas U de Queiroz wrote at Thu Apr 9 17:39:17 PDT 2020: > This was reported to me here: > https://github.com/openwrt/openwrt/commit/dcf3e63a35d05e7e5103819c0f17195bfafe9baa#commitcomment-38390450 > The update to kconfig-v5.6 broke TARGET_MULTI_PROFILE because it would not accept bool TARGET_DEVICE_<dev> to select MODULE_DEFAULT_<pkg> because MODULE_DEFAULT_<pgk> 'depends on m'--should only have a 'n' or 'm' value. A 'y' value would imply an unmet direct dependency (depends on m). > > My first thought was OK, if it wants to be a 'y', get rid of the 'depends on m' line; that did not work, because MODULE_DEFAULT_<pkg> selects PACKAGE_pkg, then <pkg> would be forced to be built-in. > So, unless someone has a better idea, let's revert to the old behavior, and tolerate some 'unmet dependencies' once again. Hopefully this gets fixed soon, as I have a hunch that this broke pretty much all TARGET_MULTI_PROFILE builds that have varying key components (like wifi firmware). Possibly also buildbot snapshots, as e.g. in ipq806x the included wifi firmware file varies by device. I noticed a problem with my own multi-device builds, and there is now forum dicsussion about an issue, which I think is related to this: https://forum.openwrt.org/t/wireless-fails-on-snapshot-r12900-kernel-5-4-on-c2600-ipq806x/60155/1 Applying the patch propsed here helped to fix my ath79 multi-device build.
Hannu Nyman <hannu.nyman@iki.fi> [2020-04-11 09:00:11]:
Hi,
> Applying the patch propsed here helped to fix my ath79 multi-device build.
So can this be interpreted as your `Tested-by:` ? Thanks.
-- ynezz
Petr Štetiar kirjoitti 11.4.2020 klo 12.43: > Hannu Nyman <hannu.nyman@iki.fi> [2020-04-11 09:00:11]: > > Hi, > >> Applying the patch propsed here helped to fix my ath79 multi-device build. > So can this be interpreted as your `Tested-by:` ? Thanks. > > -- ynezz Yes, it can. Hannu
diff --git a/scripts/config/README b/scripts/config/README index 81243e8016..d193050ba4 100644 --- a/scripts/config/README +++ b/scripts/config/README @@ -22,7 +22,9 @@ OpenWrt Buildroot: that may cause one. - use pre-built *.lex.c *.tab.[ch] files by default, to avoid depending on flex & bison. Rebuild/remove these files only if running make with - BUILD_SHIPPED_FILES defined + BUILD_SHIPPED_FILES defined. + - allow a bool symbol to select a tristate symbol that depends on m (i.e. + a package that should only be built as a module). For a full list of changes, see the repository at: https://github.com/cotequeiroz/linux/commits/openwrt/scripts/kconfig diff --git a/scripts/config/symbol.c b/scripts/config/symbol.c index 5c6f540314..051472238d 100644 --- a/scripts/config/symbol.c +++ b/scripts/config/symbol.c @@ -205,7 +205,7 @@ static void sym_calc_visibility(struct symbol *sym) tri = yes; if (sym->dir_dep.expr) tri = expr_calc_value(sym->dir_dep.expr); - if (tri == mod && sym_get_type(sym) == S_BOOLEAN) + if (tri == mod) tri = yes; if (sym->dir_dep.tri != tri) { sym->dir_dep.tri = tri;
kconfig-v5.6 disallowed a bool symbol to select another symbol that 'depends on m' (i.e. can be only 'm' on 'n'). It is, in fact, an unmet dependency to have set to 'y'. However, openwrt depends on the previous behavior, to be able to build a package that can be a module or built-in depending on a bool config. This restores the previous behavior. Signed-off-by: Eneas U de Queiroz <cotequeiroz@gmail.com> -- This was reported to me here: https://github.com/openwrt/openwrt/commit/dcf3e63a35d05e7e5103819c0f17195bfafe9baa#commitcomment-38390450 The update to kconfig-v5.6 broke TARGET_MULTI_PROFILE because it would not accept bool TARGET_DEVICE_<dev> to select MODULE_DEFAULT_<pkg> because MODULE_DEFAULT_<pgk> 'depends on m'--should only have a 'n' or 'm' value. A 'y' value would imply an unmet direct dependency (depends on m). My first thought was OK, if it wants to be a 'y', get rid of the 'depends on m' line; that did not work, because MODULE_DEFAULT_<pkg> selects PACKAGE_pkg, then <pkg> would be forced to be built-in. So, unless someone has a better idea, let's revert to the old behavior, and tolerate some 'unmet dependencies' once again.