All of lore.kernel.org
 help / color / mirror / Atom feed
From: Yann E. MORIN <yann.morin.1998@free.fr>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH 1/1] core: enhance printvars for variables with newlines
Date: Tue, 3 Apr 2018 18:21:56 +0200	[thread overview]
Message-ID: <20180403162156.GA2335@scaer> (raw)
In-Reply-To: <CAOJ2eMeFDWoG4Xj5tESgxNxxW0PefLHu1+o+ccV+0Nx9H_3yOg@mail.gmail.com>

Stefan, All,

On 2018-04-03 18:15 +0300, Stefan Becker spake thusly:
> Hi,
> 
> On Tue, Apr 3, 2018 at 5:50 PM, Thomas Petazzoni
> <thomas.petazzoni@bootlin.com> wrote:
> >
> > Just curious, what is the use case for feeding the printvars output
> > back into GNU Make ?
> 
> Short answer: because we have factored out buildroot image creation
> step to a separate build.
> 
> Previously it was enough to provide the SDK, output/target/ and a
> selected list of source *.mk file s from the "upstream" buildroot
> build to be able to do that. With todays @master update the root fs
> creation requires internal variables, like PACKAGES_USERS, to be set
> correctly to create a valid, bootable image. Which took me a while to
> root cause...

The real solution IMHO is that you base your iamge creatikon out of the
rootfs.tar image generated by Buildroot.

If you are using a br2-external tree, you can also define your own
filesystem iamge type that depends on rootfs.tar. Then your image
generator (or a wrapper around that) would extract (under fakeroot)
rootfs.tar, and generate your own image format out of that.

(Note: this is not a reason not to apply your patch, of course, just an
alternate solution for your use-case).

Regards,
Yann E. MORIN.

> Hence we need to use "printvars" to extract the content of those
> internal variables from the "upstream" buildroot build into a .mk file
> that is passed down to the "downstream" image build, which include's
> it in its top-level Makefile (a stripped-down version of buildroot
> top-level Makefile). The variables we are interested in unfortunately
> contain newlines.
> 
> Regards, Stefan

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

  reply	other threads:[~2018-04-03 16:21 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-03 14:31 [Buildroot] [PATCH 1/1] core: enhance printvars for variables with newlines Stefan Becker
2018-04-03 14:50 ` Thomas Petazzoni
2018-04-03 15:15   ` Stefan Becker
2018-04-03 16:21     ` Yann E. MORIN [this message]
2018-04-03 16:37       ` Stefan Becker
2018-04-03 17:01         ` Yann E. MORIN
2018-04-05  6:20 ` Stefan Becker

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=20180403162156.GA2335@scaer \
    --to=yann.morin.1998@free.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 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.