[Buildroot] [Bug 9866] New: BASE_DIR usage

[Buildroot] [Bug 9866] New: BASE_DIR usage

[bugzilla at busybox.net]

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 ?

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Buildroot] [Bug 9866] BASE_DIR usage

[bugzilla at busybox.net]

https://bugs.busybox.net/show_bug.cgi?id=9866

--- Comment #1 from Thomas Petazzoni <thomas.petazzoni@free-electrons.com> ---
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?

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Buildroot] [Bug 9866] BASE_DIR usage

[bugzilla at busybox.net]

https://bugs.busybox.net/show_bug.cgi?id=9866

--- Comment #2 from Jean-pierre Cartal <jpcartal@free.fr> ---
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.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Buildroot] [Bug 9866] BASE_DIR usage

[bugzilla at busybox.net]

https://bugs.busybox.net/show_bug.cgi?id=9866

Yann E. MORIN <yann.morin.1998@free.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |yann.morin.1998 at free.fr

--- Comment #3 from Yann E. MORIN <yann.morin.1998@free.fr> ---
Try with something like:

    make -C "$(dirname "${BR2_CONFIG}")" printvars

Ideally, 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.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Buildroot] [Bug 9866] BASE_DIR usage

[bugzilla at busybox.net]

https://bugs.busybox.net/show_bug.cgi?id=9866

--- Comment #4 from Peter Korsgaard <jacmet@uclibc.org> ---
(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

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Buildroot] [Bug 9866] BASE_DIR usage

[bugzilla at busybox.net]

https://bugs.busybox.net/show_bug.cgi?id=9866

--- Comment #5 from Yann E. MORIN <yann.morin.1998@free.fr> ---
(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...)

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Buildroot] [Bug 9866] BASE_DIR usage

[bugzilla at busybox.net]

https://bugs.busybox.net/show_bug.cgi?id=9866

--- Comment #6 from Peter Korsgaard <jacmet@uclibc.org> ---
(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.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Buildroot] [Bug 9866] BASE_DIR usage

[bugzilla at busybox.net]

https://bugs.busybox.net/show_bug.cgi?id=9866

Yann E. MORIN <yann.morin.1998@free.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |INVALID

--- Comment #7 from Yann E. MORIN <yann.morin.1998@free.fr> ---
Jean-Pierre,

I'm marking this patch as invalid, because this is not really a bug.

Thanks for the report.

-- 
You are receiving this mail because:
You are on the CC list for the bug.