Buildroot Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Jeremy Rosen <jeremy.rosen@openwide.fr>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH] BR2_EXTERNAL: check it is a valid BR2_EXTERNAL dir before using it
Date: Wed, 22 Jan 2014 10:00:40 +0100 (CET)	[thread overview]
Message-ID: <1751679476.4596486.1390381240766.JavaMail.root@openwide.fr> (raw)
In-Reply-To: <1390338297-733-1-git-send-email-yann.morin.1998@free.fr>

ok, I tried your patch and I have a couple of problems

I'm still trying my use-case (I'm only half convinced it's uesfull at
this point, but it's still supposed to work, which is a good enough 
reason to try to understand what's going on)


with the tmp/ directory containing only the buildroot subdirectory
i get:

rosen at pcrosen:~/tmp/buildroot$ LANG=C make O=.. BR2_EXTERNAL=.. raspberrypi_defconfig
Makefile:126: *** BR2_EXTERNAL='..' does not exist, relatively to /home/rosen/tmp/buildroot.  Stop.


Which is a confusing error message, the problem is that I don't have
a Config.in and external.mk file  in tmp /(which are mandatory in
BR2_EXTERNAL though that's not stated in the doc afaics)

once that is fixed, that command line still creates the infinite
recursion on calling defconfig. So that doesn't solve that particular issue...



----- Mail original -----
> From: "Yann E. MORIN" <yann.morin.1998@free.fr>
> 
> Using a relative path for BR2_EXTERNAL, and using an external
> defconfig,
> such as in (from a Buildroot top-dir):
>     make O=.. BR2_EXTERNAL=.. foo_defconfig
> 
> is broken. It is unclear why the %_defconfig rule recurses in that
> case,
> but using relative paths is inherently broken.
> 
> This patch first makes BR2_EXTERNAL canonical (ie. makes it an
> absolute
> path). Then we check this path exists and contains a valid
> BR2_EXTERNAL
> tree, by checking external.mk and Config.in exist.
> 
> The manual is updated to discourage using relative paths.
> 
> Also, a note is added to the O documentation that relative paths are
> discouraged as well.
> 
> Reported-by: J?r?my Rosen <jeremy.rosen@openwide.fr>
> Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
> Cc: Peter Korsgaard <jacmet@uclibc.org>
> Cc: Romain Naour <romain.naour@openwide.fr>
> ---
>  Makefile                             | 10 +++++++++-
>  docs/manual/common-usage.txt         | 13 ++++++++++---
>  docs/manual/customize-outside-br.txt | 12 +++++++-----
>  3 files changed, 26 insertions(+), 9 deletions(-)
> 
> diff --git a/Makefile b/Makefile
> index 9dfb1e0..5753f81 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -118,7 +118,15 @@ ifeq ($(BR2_EXTERNAL),)
>    override BR2_EXTERNAL = support/dummy-external
>    $(shell rm -f $(BR2_EXTERNAL_FILE))
>  else
> -  $(shell echo BR2_EXTERNAL ?= $(BR2_EXTERNAL) >
> $(BR2_EXTERNAL_FILE))
> +  _BR2_EXTERNAL = $(shell cd $(BR2_EXTERNAL) >/dev/null 2>&1 && pwd)
> +  ifeq ($(and $(_BR2_EXTERNAL),$(wildcard
> $(_BR2_EXTERNAL)/external.mk),$(wildcard
> $(_BR2_EXTERNAL)/Config.in)),)
> +    ifeq ($(patsubst /%,/,$(BR2_EXTERNAL)),)
> +      $(error BR2_EXTERNAL='$(BR2_EXTERNAL)' does not exist)
> +    else
> +      $(error BR2_EXTERNAL='$(BR2_EXTERNAL)' does not exist,
> relatively to $(TOPDIR))
> +    endif
> +  endif
> +  $(shell echo BR2_EXTERNAL ?= $(_BR2_EXTERNAL) >
> $(BR2_EXTERNAL_FILE))
>  endif
>  
>  # Need that early, before we scan packages
> diff --git a/docs/manual/common-usage.txt
> b/docs/manual/common-usage.txt
> index 1d15c05..ca44b10 100644
> --- a/docs/manual/common-usage.txt
> +++ b/docs/manual/common-usage.txt
> @@ -40,7 +40,8 @@ Or:
>   $ cd /tmp/build; make O=$PWD -C path/to/buildroot
>  --------------------
>  
> -All the output files will be located under +/tmp/build+.
> +All the output files will be located under +/tmp/build+. If the +O+
> +path does not exist, Buildroot will create it.
>  
>  When using out-of-tree builds, the Buildroot +.config+ and temporary
>  files are also stored in the output directory. This means that you
>  can
> @@ -48,13 +49,19 @@ safely run multiple builds in parallel using the
> same source tree as
>  long as they use unique output directories.
>  
>  For ease of use, Buildroot generates a Makefile wrapper in the
>  output
> -directory - so after the first run, you no longer need to pass
> +O=..+
> -and +-C ..+, simply run (in the output directory):
> +directory - so after the first run, you no longer need to pass
> +O=<...>+
> +and +-C <...>+, simply run (in the output directory):
>  
>  --------------------
>   $ make <target>
>  --------------------
>  
> +The +O+ path can be either an absolute or a relative path, but if
> it's
> +passed as a relative path, it is important to note that it is
> interpreted
> +relative to the main Buildroot source directory, not the current
> working
> +directory. Using relative paths can lead to various broken setups,
> and
> +thus is highly discouraged in favour of using absolute paths.
> +
>  [[env-vars]]
>  
>  Environment variables
> diff --git a/docs/manual/customize-outside-br.txt
> b/docs/manual/customize-outside-br.txt
> index 19257e6..53d88d7 100644
> --- a/docs/manual/customize-outside-br.txt
> +++ b/docs/manual/customize-outside-br.txt
> @@ -32,16 +32,18 @@ removed by passing an empty value.
>  
>  The +BR2_EXTERNAL+ path can be either an absolute or a relative
>  path,
>  but if it's passed as a relative path, it is important to note that
>  it
> -is interpreted relatively to the main Buildroot source directory,
> not
> -the Buildroot output directory.
> +is interpreted relative to the main Buildroot source directory, not
> +the Buildroot output directory. Using relative paths can lead to
> various
> +broken setups, and thus is highly discouraged in favour of using
> +absolute paths.
>  
>  Some examples:
>  
>  -----
> - buildroot/ $ make BR2_EXTERNAL=../foobar menuconfig
> + buildroot/ $ make BR2_EXTERNAL=/path/to/foobar menuconfig
>  -----
>  
> -Starting from now on, external definitions from the +../foobar+
> +Starting from now on, external definitions from the
> +/path/to/foobar+
>  directory will be used:
>  
>  -----
> @@ -52,7 +54,7 @@ directory will be used:
>  We can switch to another external definitions directory at any time:
>  
>  -----
> - buildroot/ $ make BR2_EXTERNAL=../barfoo xconfig
> + buildroot/ $ make BR2_EXTERNAL=/where/we/have/barfoo xconfig
>  -----
>  
>  Or disable the usage of external definitions:
> --
> 1.8.1.2
> 
> 

  reply	other threads:[~2014-01-22  9:00 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-01-21 21:04 [Buildroot] [PATCH] BR2_EXTERNAL: check it is a valid BR2_EXTERNAL dir before using it Yann E. MORIN
2014-01-22  9:00 ` Jeremy Rosen [this message]
2014-01-22 10:21   ` yann.morin.1998 at free.fr
2014-01-22 12:43     ` Jeremy Rosen
2014-01-22 21:10       ` Yann E. MORIN
2014-01-22 18:55   ` Yann E. MORIN

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1751679476.4596486.1390381240766.JavaMail.root@openwide.fr \
    --to=jeremy.rosen@openwide.fr \
    --cc=buildroot@busybox.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox