New: BASE_DIR usage
https://bugs.busybox.net/show_bug.cgi?id=9866
Bug ID: 9866
Summary: BASE_DIR usage
Product: buildroot
Version: 2017.02
Hardware: All
OS: Linux
Status: NEW
Severity: enhancement
Priority: P5
Component: Other
Assignee: unassigned at buildroot.uclibc.org
Reporter: jpcartal at free.fr
CC: buildroot at uclibc.org
Target Milestone: ---
I'm trying to use the printvars target from a post image shell script and I would like this script to support both default output directory ie buildroot/output as well as O= option.
Thus I'm calling the printvars target as follow :
make -C ${BASE_DIR} printvars
However this code will only work if O= option is used, since in this case the BASE_DIR directory will contain the main Makefile.
Is there any variable that will contain the directory which contains the main Makefile file ?
Wouldn't it be more coherent if the BASE_DIR would point to directories with similar content without depending on O= option ?
Signature · 2 lines
You are receiving this mail because: You are on the CC list for the bug.
[Buildroot] [Bug 9866] BASE_DIR usage
https://bugs.busybox.net/show_bug.cgi?id=9866
--- Comment #1 from Thomas Petazzoni <[email protected]> --- According to the Buildroot manual:
"Again just like for the post-build scripts, the scripts have access to the environment variables BR2_CONFIG, HOST_DIR, STAGING_DIR, TARGET_DIR, BUILD_DIR, BINARIES_DIR and BASE_DIR."
So why bother re-running make printvars to get BASE_DIR, if it's already available in the environment?
Signature · 2 lines
You are receiving this mail because: You are on the CC list for the bug.
[Buildroot] [Bug 9866] BASE_DIR usage
In reply to bugzilla at busybox.nethttps://bugs.busybox.net/show_bug.cgi?id=9866
--- Comment #2 from Jean-pierre Cartal <[email protected]> --- Sorry, my explanation was not clear enough.
Let's try again ;-)
I have several build environments, some are using out-of-tree builds using the -O option, others are using the default output location.
Now let's say I want to get the value of BR2_ARCH variable in the post image shell script using the printvars target, I need to find the location of the Makefile I should use.
My idea was to use the already available BASE_DIR variable as follow :
make -C ${BASE_DIR} printvars
This is working fine for out-of-tree environments, since the ${BASE_DIR}/Makefile file will point to the makefile wrapper. However for default build environment, ${BASE_DIR} will point to the output directory where there is no Makefile available.
For the time being I added a test in my script as follow :
#Out-of-tree build case
if [ ${BASE_DIR}/Makefile ] ; then
make -C ${BASE_DIR} printvars
# default build environment case.
else
make -C ${BASE_DIR}/../ printvars
fi;So I had several questions :
1) Am I using the correct method to get the current build Makefile location ?
2) Wouldn't it be more consistent for ${BASE_DIR} to always point to a location with the same content/structure for default and out-of-tree builds or maybe to have another variable that would give access to current build Makefile location ?
Thanks for your help.
Signature · 2 lines
You are receiving this mail because: You are on the CC list for the bug.
[Buildroot] [Bug 9866] BASE_DIR usage
In reply to bugzilla at busybox.nethttps://bugs.busybox.net/show_bug.cgi?id=9866
Yann E. MORIN <[email protected]> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |yann.morin.1998 at free.fr
--- Comment #3 from Yann E. MORIN <[email protected]> --- Try with something like:
make -C "$(dirname "${BR2_CONFIG}")" printvarsIdeally, we would export CNFIG_DIR (which is exactly the directory you get above), but CONFIG_DIR clashes with various buildsystems, like (IIRC) U-Boot...
Regards,
Yann E. MORIN.
Signature · 2 lines
You are receiving this mail because: You are on the CC list for the bug.
[Buildroot] [Bug 9866] BASE_DIR usage
In reply to bugzilla at busybox.nethttps://bugs.busybox.net/show_bug.cgi?id=9866
--- Comment #4 from Peter Korsgaard <[email protected]> --- (In reply to Yann E. MORIN from comment #3)
Actually you don't need to do anything like that. All scripts are executed from the buildroot toplevel directory, so the only thing you need to do is to ensure the correct .config is used (.config or $(O)/.config). This is taken care by the BR2_CONFIG variable, so just do:
make BR2_CONFIG=$BR2_CONFIG printvars
Signature · 2 lines
You are receiving this mail because: You are on the CC list for the bug.
[Buildroot] [Bug 9866] BASE_DIR usage
In reply to bugzilla at busybox.nethttps://bugs.busybox.net/show_bug.cgi?id=9866
--- Comment #5 from Yann E. MORIN <[email protected]> --- (In reply to Peter Korsgaard from comment #4)
Except that in this case you'll be missing on any br2-external tree, or any local.mk, as:
- br2-external is set in .br-external in CONFIG_DIR
- local.mk is by default in CONFIG_DIR
but CONFIG_DIR is not in .config...
In retrospect, I think we should just export CONFIG_DIR, as it's CONFIG that can clash, not CONFIG_DIR (AFAICS...)
Signature · 2 lines
You are receiving this mail because: You are on the CC list for the bug.
[Buildroot] [Bug 9866] BASE_DIR usage
In reply to bugzilla at busybox.nethttps://bugs.busybox.net/show_bug.cgi?id=9866
--- Comment #6 from Peter Korsgaard <[email protected]> --- (In reply to Yann E. MORIN from comment #5)
Ahh yes, as you can see I don't use BR2_EXTERNAL (and local.mk normally doesn't matter for a post-build / post-image script).
Grepping the linux and u-boot sources, I do see some references to CONFIG_DIR though, so we have to be careful.
Signature · 2 lines
You are receiving this mail because: You are on the CC list for the bug.
[Buildroot] [Bug 9866] BASE_DIR usage
In reply to bugzilla at busybox.nethttps://bugs.busybox.net/show_bug.cgi?id=9866
Yann E. MORIN <[email protected]> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |INVALID--- Comment #7 from Yann E. MORIN <[email protected]> --- Jean-Pierre,
I'm marking this patch as invalid, because this is not really a bug.
Thanks for the report.
Signature · 2 lines
You are receiving this mail because: You are on the CC list for the bug.