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 19:01:19 +0200	[thread overview]
Message-ID: <20180403170119.GC2335@scaer> (raw)
In-Reply-To: <CAOJ2eMfXU5NruPy3KXtNVm_2geCiLysSGw-C5T9jQvmRMv+4vw@mail.gmail.com>

Stefan, All,

On 2018-04-03 19:37 +0300, Stefan Becker spake thusly:
> Hi,
> On Tue, Apr 3, 2018 at 7:21 PM, Yann E. MORIN < [1]yann.morin.1998@free.fr> wrote:
> 
>   The real solution IMHO is that you base your iamge creatikon out of the
>   rootfs.tar image generated by Buildroot.
> 
> I'm not sure that is feasible, because then you would loose access to things that need to be done inside fakeroot (f.ex.).

Of course, as I wrote below, your script that does the work woudl need
to run under fakeroot, obviously. This can be easily achieved with a
snippet like that:

    #!/bin/sh

    if [ $(id -u) -ne 0 ]; then
        fakeroot "${0]" "${@}"
        exit ${?}
    fi

    # here goes your real filesystem code...

> Plus @master the new rootfs-common.tar has been added, but the build deletes it again and thus it can't be exported as build
> artifact.

Beause this is only an internal temporary file that you should not be
concerned with. Besides, it is not even totaly complete either...

I was talking about the *real* final rootfs.tar that you get with
BR2_TARGET_ROOTFS_TAR.

>   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.
> 
> ...which would mean we are back in the slow monolithic meta build
> system with our components. Sorry, but that won't do :-)

Of course, if you are trying to fast-track Buildroot with local hacks,
you are back on your own...

> BTW: we do have a br2-external tree but it is basically "pure". It is only needed so that we do not pollute the buildroot tree with
> things that are needed to run the buildroot build system and create the build artifacts afterwards.

Sorry, I don't understand what you mean by "pure". There is no "purity"
to talk of about a br2-external tree: by definition, you put in there
whatever you want. You probably meant that you are not touching the
buildroot tree. Yes, I understand. But nothing prevents you from putting
your own filesystem (or rather, image) generation tool as a new
filesystem type. See for example what I explained at ELCE last year:

    https://elinux.org/images/8/8e/2017-10-24_-_ELCE-Buildroot.pdf (slide 16)
    https://youtu.be/SN2hYO2rYtk?t=728

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  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 17:01 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
2018-04-03 16:37       ` Stefan Becker
2018-04-03 17:01         ` Yann E. MORIN [this message]
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=20180403170119.GC2335@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.