From: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH 0/1] system/Config.in: introduce pre-build script
Date: Sun, 2 Feb 2020 10:04:32 +0100 [thread overview]
Message-ID: <20200202100432.1ada7720@windsurf> (raw)
In-Reply-To: <20200121230956.23129-1-mmayer@broadcom.com>
Hello Markus,
On Tue, 21 Jan 2020 15:09:55 -0800
Markus Mayer <mmayer@broadcom.com> wrote:
> Specifically, we are building ARM64 images that also contain a 32-bit
> run-time environment from an Aarch32 toolchain (just the shared libraries
> and ld.so from sys-root, nothing fancier than that). -- No, we aren't doing
> this for fun, but because there are some binaries, which we don't have the
> sources for, that only come as 32-bit variants and they need to be able to
> execute in an ARM64 environment, as well.
>
> We used to use /lib64 and /lib to store the shared libraries in the target
> file system. However, we have come to realize that using /lib and /lib32
> makes a lot of things much easier (/lib64 merely becomes a symlink to /lib
> in this setup) and began the transition.
>
> However, introducing the change leads to a problem for developers they don't
> expect: they simply update their GIT repo as they are used to doing, and
> suddenly their already existing build is inconsistent with what is now
> expected, whereas in the past it has always been possible to do an
> incremental build even after a "git pull."
We simply don't support incremental builds like you describe, i.e there
is no way for Buildroot to guarantee after a "git pull" and a partial
rebuild with just "make" that changes will be taken into account. A
simple thing that adding a new --enable-foo option in a package that
has already been built will not see this package being rebuilt when
running "make".
So, while there may possibly be other situations where a pre-build
script could be useful, your particular use-case is not a very
convincing argument at all, because it clearly falls outside of what
Buildroot supports.
So what would be nice to see is if there are other use-cases for a
pre-build script that make sense.
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
prev parent reply other threads:[~2020-02-02 9:04 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-21 23:09 [Buildroot] [PATCH 0/1] system/Config.in: introduce pre-build script Markus Mayer
2020-01-21 23:09 ` [Buildroot] [PATCH 1/1] " Markus Mayer
2022-01-06 10:53 ` Arnout Vandecappelle
2020-02-02 9:04 ` Thomas Petazzoni [this message]
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=20200202100432.1ada7720@windsurf \
--to=thomas.petazzoni@bootlin.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 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.