FS#3441 - Menuconfig misbehaviour: wpad-mesh-wolfssl disappears depending on wpad-basic state #8312
I am on OpenWrt 19.07.4 and menuconfig is behaving weirdly in a case.
Selecting at the same time wpad-basic and wpad-mesh-wolfssl causes a clash of files installation in the compilation process. For this reason the deselection of wpad-basic has been suggested in LibreMesh compilation instructions.
wpad-mesh-wolfssl can be selected in menuconfig and wpad-basic deselected, until here everything ok.
Then when closing and opening again menuconfig, wpad-mesh-wolfssl is not visible.
But when wpad-basic (or something else) is selected, wpad-mesh-wolfssl appears and is actually selected (as it should be).
The wpad-mesh-wolfssl package is categorized as being inside wpad-mesh-openssl, which makes no sense.
And all of this happens even if the definitions of wpad-basic, wpad-mesh-openssl and wpad-mesh-wolfssl are substantially identical (extracted from https://github.com/openwrt/openwrt/blob/openwrt-19.07/package/network/services/hostapd/Makefile ):
This looks like a bug in some of the Config.in files used by make menuconfig.
The text was updated successfully, but these errors were encountered:
Additional scenario that makes this issue more annoying:
This means that every time I modify something in the menuconfig, I have to select again the wpad-mesh-wolfssl package.
In order to understand something I did a traceback, I report it here more as a note to myself:
menuconfig uses mconf
mconf represents the data from "tmp/.config-package.in"
depends on m || (PACKAGE_wpad-mesh-openssl != y)
"tmp/.configure-package.in" gets generated by "scripts/package-metadata.pl config"
"scripts/package-metadata.pl config" takes the info from "tmp/.packageinfo"
here the wpad-mesh-wolfssl has wpad-mesh-openssl mentioned between the conflicts, but the opposite does not happen
"tmp/.packageinfo" gets generated by "include/scan.mk"
"include/scan.mk" gets invokated by "include/toplevel.mk" with (in case it was useful for easing the troubleshooting):
TOPDIR=$(pwd) make -j1 -r -s -f include/scan.mk SCAN_TARGET="packageinfo" SCAN_DIR="package" SCAN_NAME="package" SCAN_DEPTH=5 SCAN_EXTRA=""
"include/scan.mk" merges many files from "tmp/info/", the interesting one is ".packageinfo-network_services_hostapd"
the "tmp/info/.packageinfo-network_services_hostapd" is also generated by the scan.mk call
"include/scan.mk" calls make in plenty of directories, between which also "package/network/services/hostapd"
TOPDIR=$(pwd) INCLUDE_DIR=$(pwd)/include make V=ss --no-print-dir -r DUMP=1 FEED="" -C package/network/services/hostapd
and this creates the Conflicts list from the $CONFLICTS variable set inside "package/network/services/hostapd/Makefile" so that after a few hours of looking into the issue turns out that the issue was in the most logical place.
gets populated as the things get defined across the Makefile, so that at the moment of defining wpad-mesh-openssl, these variables do not contain any wpad-mesh-*. At this point, wpad-mesh-openssl gets added there.
This means that each package has a non-complete conflicting packages list depending on when it gets defined inside the Makefile.
And when running the menuconfig thereś also a funny message stating:
tmp/.config-package.in:139918:error: recursive dependency detected!
I am still having problems with this on v22.03.3.
check the content of the
as you can see,
Is there a way for having the full wpad-openssl compiled in the firmware using the buildroot?
Selecting a package with a dependency from wpad-openssl (this package: https://github.com/libremesh/network-profiles/blob/master/calafou/outdoor-crypt/Makefile ) seems that managed to keep wpad-openssl selected.