All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Yann E. MORIN" <yann.morin.1998@free.fr>
To: Fiona Klute <fiona.klute@gmx.de>
Cc: Ricardo Martincoski <ricardo.martincoski@datacom.com.br>,
	Brandon Maier <brandon.maier@collins.com>,
	Thomas Petazzoni <thomas.petazzoni@bootlin.com>,
	buildroot@buildroot.org
Subject: Re: [Buildroot] [PATCH v3 1/2] utils/docker-run: mount and pass BR2_EXTERNAL dirs
Date: Sat, 31 Aug 2024 20:14:09 +0200	[thread overview]
Message-ID: <ZtNdccT-tuO4Epk2@landeda> (raw)
In-Reply-To: <ae8a1d19-00a8-4be4-a16f-a951cba5e9f9@gmx.de>

Fiona, All,

On 2024-08-31 18:57 +0200, Fiona Klute spake thusly:
> Am 30.08.24 um 23:35 schrieb Yann E. MORIN:
> > On 2024-07-13 21:22 +0200, Fiona Klute via buildroot spake thusly:
> > > From: "Fiona Klute (WIWA)" <fiona.klute@gmx.de>
> > > The BR2_EXTERNAL environment variable is passed into the container,
> > > and each path listed in it mounted. This allows using external trees
> > > when running a build using utils/docker-run. Testing the existence of
> > > the variable instead of a non-empty value allows passing an empty
> > > BR2_EXTERNAL variable to disable currently set external trees.
[--SNIP--]
> > This commit mixes multiple changes:
> >    - using process substitution with a while-loop, instead of the
> >      command substitution and a for-loop
> >    - passing br2-external and mounting trees in the container
> >    - handling br2-external trees with spaces in them
> > 
> > I see you have a second patch with support for br2-external trees with
> > spaces in their paths. If at all, it should come before this one.
> > 
> > However, I don't think we should support paths with spaces. We currently
> > do not, and the rest of the code base (as your second patch states) may
> > or may not work (hint: it does not, it's broken in a lot of places, and
> > the buildsystems of many packages do not support spaces in path either).
> > 
> > Also, BR2_EXTERNAL must be a space-separated list, as it needs to be
> > split on space from Makefile context, so no br2-external tree with
> > spaces in paths can even work... (unless I missed something...)
> 
> According to the manual multiple paths in BR2_EXTERNAL must be separated
> by colons, not spaces, example copied verbatim from
> docs/manual/customize-outside-br.adoc:
> 
> buildroot/ $ make BR2_EXTERNAL=/path/to/foo:/where/we/have/bar menuconfig

Supporting both colon- and space-separated lists was the worst idea I
had when I implemented and coded support for mutliple br2-externals.

In fact, the manual has an example with a colon, but nowhere does it
explicitly states that it can be either.

> support/scripts/br2-external splits BR2_EXTERNAL by colon, or rather
> replaces colons with spaces in the variable value and then uses the
> result unquoted to create a list of parameters.

Note that the code (which you quoted in your reply to patch 2) is:

    do_validate "${outputdir}" ${@//:/ }

So, it is going to split the words on spaces. E.g. passing:
    BR2_EXTERNAL=/path/to some/dir:/other/path

will result in this call:

    do_validate "${outputdir}" /path/to some/dir /other/path

which will be three arguments. And that would fail:

    $ BR2_EXTERNAL="/home/ymorin/dev/buildroot/misc/br2-external-tests/br2-external-1:/home/ymorin/dev/buildroot/misc/br2-external-tests/br2 external" make defconfig
    Makefile:194: *** '/home/ymorin/dev/buildroot/misc/br2-external-tests/br2': no such file or directory.  Stop.
    make: *** [Makefile:23: _all] Error 2

(I need to polish and push my br2-external test trees to gitlab...)

Also, internally, BR2_EXTERNAL is saved back as a space-separated list:

    https://gitlab.com/buildroot.org/buildroot/-/blob/master/support/scripts/br2-external?ref_type=heads#L124

    printf 'BR2_EXTERNAL ?='
    for br2_name in "${BR2_EXT_NAMES[@]}"; do
        eval br2_ext="\"\${BR2_EXT_PATHS_${br2_name}}\""
        printf ' %s' "${br2_ext}"
    done
    printf '\n'

... so that calling 'make' again without specifyig BR2_EXTERNAL will
still use the BR2_EXTERNAL trees used at configure time.

So, definitely, br2-external trees with spaces in them is not supported
and is not working.

> That means
> utils/docker-run must split by colon, too, no matter if we want to make
> the handling of the individual paths after splitting space-safe or not.

Damn right you are, damit! ;-) So the code could just look like:

     docker_opts+=( --env BR2_EXTERNAL )
     for dir in ${BR2_EXTERNAL//:/ }; do
         mountpoints+=( "${br2_ext}" )
     done

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 561 099 427 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

  reply	other threads:[~2024-08-31 18:14 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-07-13 19:22 [Buildroot] [PATCH v3 1/2] utils/docker-run: mount and pass BR2_EXTERNAL dirs Fiona Klute via buildroot
2024-07-13 19:22 ` [Buildroot] [PATCH v3 2/2] support/scripts/br2-external: allow spaces in dirname Fiona Klute via buildroot
2024-07-13 19:38   ` Brandon Maier via buildroot
2024-08-30 21:38   ` Yann E. MORIN
2024-08-31 17:07     ` Fiona Klute via buildroot
2024-07-13 19:38 ` [Buildroot] [PATCH v3 1/2] utils/docker-run: mount and pass BR2_EXTERNAL dirs Brandon Maier via buildroot
2024-08-30 21:35 ` Yann E. MORIN
2024-08-31 16:57   ` Fiona Klute via buildroot
2024-08-31 18:14     ` Yann E. MORIN [this message]
2024-08-31 19:22       ` Fiona Klute via buildroot

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=ZtNdccT-tuO4Epk2@landeda \
    --to=yann.morin.1998@free.fr \
    --cc=brandon.maier@collins.com \
    --cc=buildroot@buildroot.org \
    --cc=fiona.klute@gmx.de \
    --cc=ricardo.martincoski@datacom.com.br \
    --cc=thomas.petazzoni@bootlin.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.