buildroot.busybox.net archive mirror
 help / color / mirror / Atom feed
From: Thomas De Schampheleire <patrickdepinguin@gmail.com>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH] package/pkg-meson: ensure the global cross-compilation.conf file is correct
Date: Fri, 6 Dec 2019 11:16:45 +0100	[thread overview]
Message-ID: <CAAXf6LU3+uNVLKCK-P6iinaQ7-0FhuAWyJB_3fHfF-roFCd6zA@mail.gmail.com> (raw)
In-Reply-To: <20191206105712.56765a03@windsurf>

El vie., 6 dic. 2019 a las 10:57, Thomas Petazzoni
(<thomas.petazzoni@bootlin.com>) escribi?:
>
> On Fri, 6 Dec 2019 10:54:13 +0100
> Thomas De Schampheleire <patrickdepinguin@gmail.com> wrote:
>
> > Needless to say, I am opposed to moving the meson file back from the
> > target-finalize step :-)
> > I think most of the reasoning was already mentioned in that commit,
> > but it seems I did not explain that we actually have HOST_DIR mounted
> > read-only on subsequent 'make' commands after the initial make,
> > exactly to verify that no-one is changing directories they shouldn't
> > be changing. After all, a 'make' after the initial make will only
> > normally do the target-finalize step.
>
> No, it will do staging-finalize as well. I don't think we provide the
> guarantee that HOST_DIR is unchanged/read-only between each "make"
> invocation, and I'm not sure why we would want to provide this
> guarantee.

The fact that staging-finalize is triggered from target-finalize is
also a problem in my use case, and I have cleared it in our local copy
(moving its action to another place). I think we talked about that
earlier too.

I think Yann suggested me to look into the sdk in this context. I need
to check it in more detail soon, to see whether it can really solve
this friction we have between our current needs and changes upstream.

To recap our use case: we make an initial Buildroot build, package it,
then in other machines but on the same virtual path (mounted to the
same location inside a docker container) extract it. Then,
applications are built outside of Buildroot, but stored to a copy of
the output/target directory. Then a subsequent 'make' is run to let
Buildroot package everything into an initramfs, setting TARGET_DIR to
the copy. During all these subsequent builds, the host directory and
some others are kept read-only to prevent corruption of that 'cache'.

Best regards,
Thomas

  reply	other threads:[~2019-12-06 10:16 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-04 15:02 [Buildroot] [PATCH] package/pkg-meson: ensure the global cross-compilation.conf file is correct Thomas Petazzoni
2019-12-04 16:49 ` Peter Seiderer
2019-12-05 22:13 ` Arnout Vandecappelle
2019-12-06  7:59   ` Thomas Petazzoni
2019-12-06  8:58     ` Arnout Vandecappelle
2019-12-06  9:00       ` Thomas Petazzoni
2019-12-06  9:54   ` Thomas De Schampheleire
2019-12-06  9:55     ` Thomas De Schampheleire
2019-12-06  9:57     ` Thomas Petazzoni
2019-12-06 10:16       ` Thomas De Schampheleire [this message]
2019-12-06 11:31         ` Arnout Vandecappelle
2019-12-06 20:53           ` Thomas De Schampheleire
2020-09-14 20:04 ` Yann E. MORIN
2020-09-15 19:03   ` Peter Korsgaard

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=CAAXf6LU3+uNVLKCK-P6iinaQ7-0FhuAWyJB_3fHfF-roFCd6zA@mail.gmail.com \
    --to=patrickdepinguin@gmail.com \
    --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;
as well as URLs for NNTP newsgroup(s).