Hello,
As of today, there are a few CONFIG_ variables that are used to change
the input or the result of the build process - i.e. the places where files
are stored or from where they are fetched. I haven't checked everything
but I will mention some of them:
CONFIG_DOWNLOAD_FOLDER : the place where downloaded files are stored
(and, consequently, the place from where they are retrieved during
the prepare steps).
CONFIG_BINARY_FOLDER : the bin directory where the build result is
stored
CONFIG_BUILD_SUFFIX : the suffix to add to a number of build
directories.
There might be others.
It was my impression that these variables where fully handled when they
were passed as command line arguments to the make command. For example,
if I do
make CONFIG_BUILD_SUFFIX=_my_router CONFIG_DOWNLOAD_FOLDER=/ramdisk/dl
Then it will just work.
Of course, this is correct most of the time. The few kernel_*config rules
are not honoring the command lines - meaning that if I fully built the
image with these command line vars then I cannot (for example) do a
make CONFIG_BUILD_SUFFIX=_my_router CONFIG_DOWNLOAD_FOLDER=/ramdisk/dl
kernel_menuconfig
It breaks. Here is a part of the --trace output I got for a similar command
line:
me@home:~/openwrt$ make --trace CONFIG_DOWNLOAD_FOLDER=/home/me/dl
CONFIG_BINARY_FOLDER=/home/me/bin/bpipro CONFIG_BUILD_SUFFIX=bpipro
kernel_menuconfig
/home/me/openwrt/include/toplevel.mk:69: update target 'prepare-tmpinfo'
due to: FORCE
make -r -s staging_dir/host/.prereq-build OPENWRT_BUILD= QUIET=0
mkdir -p tmp/info
export MAKEFLAGS= ;make V=s -j1 -r -s -f include/scan.mk
SCAN_TARGET="packageinfo" SCAN_DIR="package" SCAN_NAME="package"
SCAN_DEPS="/home/me/openwrt/include/package*.mk
/home/me/openwrt/overlay/*/*.mk" SCAN_DEPTH=5 SCAN_EXTRA=""
export MAKEFLAGS= ;make V=s -j1 -r -s -f include/scan.mk
SCAN_TARGET="targetinfo" SCAN_DIR="target/linux" SCAN_NAME="target"
SCAN_DEPS="profiles/*.mk /home/me/openwrt/include/kernel*.mk
/home/me/openwrt/include/target.mk" SCAN_DEPTH=2 SCAN_EXTRA=""
SCAN_MAKEOPTS="TARGET_BUILD=1"
for type in package target; do \
f=tmp/.${type}info; t=tmp/.config-${type}.in; \
[ "$t" -nt "$f" ] || ./scripts/metadata.pl ${type}_config "$f" > "$t" || {
rm -f "$t"; echo "Failed to build $t"; false; break; }; \
done
[ tmp/.config-feeds.in -nt tmp/.packagefeeds ] || ./scripts/feeds
feed_config > tmp/.config-feeds.in
./scripts/metadata.pl package_mk tmp/.packageinfo > tmp/.packagedeps || {
rm -f tmp/.packagedeps; false; }
./scripts/metadata.pl package_feeds tmp/.packageinfo > tmp/.packagefeeds ||
{ rm -f tmp/.packagefeeds; false; }
touch /home/me/openwrt/tmp/.build
/home/me/openwrt/include/toplevel.mk:83: update target '.config' due to:
prepare-tmpinfo
if [ \! -e .config ] || ! grep CONFIG_HAVE_DOT_CONFIG .config >/dev/null;
then \
[ -e /home/me/.openwrt/defconfig ] && cp /home/me/.openwrt/defconfig
.config; \
export MAKEFLAGS= ;make V=s menuconfig OPENWRT_BUILD= QUIET=0; \
fi
/home/me/openwrt/include/toplevel.mk:134: update target 'kernel_menuconfig'
due to: prepare_kernel_conf
export MAKEFLAGS= ;make V=s -C target/linux menuconfig
make[1]: Entering directory '/home/me/openwrt/target/linux'
make[2]: Entering directory '/home/me/openwrt/target/linux/mvebu'
mkdir -p /home/me/openwrt/dl
/home/me/openwrt/scripts/download.pl "/home/me/openwrt/dl"
"linux-3.18.11.tar.xz" "2def91951c9cedf7896efb864e0c090c"
"@KERNEL/linux/kernel/v3.x"
converted '
ftp://ftp.all.kernel.org/pub/linux/kernel/v3.x/linux-3.18.11.tar.xz'
(ANSI_X3.4-1968) -> '
ftp://ftp.all.kernel.org/pub/linux/kernel/v3.x/linux-3.18.11.tar.xz' (UTF-8)
--2015-04-23 19:38:01--
ftp://ftp.all.kernel.org/pub/linux/kernel/v3.x/linux-3.18.11.tar.xz
As you can see from these lines, the CONFIG_DOWNLOAD_FOLDER is ignored
(too bad because I don't have any internet access on this build
machine ; everything is already stored into a pre-built download
directory).
I identified the "culprit": the kernel_menuconfig (and the other related
rules) are calling $(_SINGLE)$(NO_TRACE_MAKE) ... - and $(_SINGLE) empties
MAKEFLAGS (export MAKEFLAGS= ;).
My problem is that I don't know how to fix this, as there might be a good
reason to do that - one I don't understand yet. My little, dirty solution
for now is to rewrtite the kernel_menuconfig rule as:
kernel_menuconfig: prepare_kernel_conf
$(_SINGLE)$(NO_TRACE_MAKE) $(filter CONFIG_%,$(MAKEFLAGS)) -C
target/linux menuconfig
Which works, but is probably not very clever.
So, a few questions:
* does someone has any information on why these kernel_*config rules
have this $(_SINGLE) here?
* is there a way to have these CONFIG_* command line variables
correctly honored in this specific case?
* is this even legal (from an OpenWRT point of view)?
Best regards,
-- Emmanuel Deloget
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
