From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
To: buildroot@busybox.net
Subject: [Buildroot] pre-built binary packages
Date: Wed, 11 Oct 2017 23:56:42 +0200 [thread overview]
Message-ID: <20171011235642.610fdc3d@windsurf.lan> (raw)
In-Reply-To: <572050367.13476787.1507757774068.JavaMail.zimbra@datacom.ind.br>
Hello,
On Wed, 11 Oct 2017 18:36:14 -0300 (BRT), Henrique Marks wrote:
> Here in Datacom we use "binary artifacts": when we build a package,
> we make a tarball of the artifacts. When we want to build the
> package, we try to use the tarball first, if the version (in the
> tarball) matches the package version.
>
> We have not contributed this solution to buildroot because it doesn't
> seem to be possible to do this in a generic way. We have this binary
> artifact generation for our internal packages (and all of them use
> cmake to build). I think it is the only patch to buildroot that we
> consider to be "eternal".
>
> You can do the same for any package: you can control what's installed
> in staging and target, and create a tarball containing these folders
> and the stamp files. Then, use this Binary, instead of the source,
> when the binary can be used (same source version, for instance).
>
> So, a compilation in our systems always starts with a "build form
> binaries" and then "rebuild some parts from source". That's way we
> would like the python script that implements show-<pkg>-rrdepends to
> be accepted upstream: combined with binary artifacts, it is possible
> to build fast (from binaries) and rebuild fast (from source).
The problem is that you don't have any reliable way to know if your
binary artifacts are valid for a given build or not.
Let's say you have a binary artifact of Qt5. But that artifact was
created with a given set of Qt5 configuration options. If you change
any Qt5 configuration option in Buildroot, then your binary artifact
should no longer be used.
The situation becomes worse with optional dependencies. You have built
package FOO, which optionally depends on BAR, but BAR was disabled. You
create a binary artifact of FOO, and re-use it to avoid rebuilding.
Later on, you enable BAR. How do you notice that your binary artifact
of FOO is no longer correct and should be rebuilt ?
So yes, you can use binary artifact, but only if you are very, very,
very, very, very careful, and you have a full and complete
understanding of what you're doing. You can shoot yourself in the foot
very easily.
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
next prev parent reply other threads:[~2017-10-11 21:56 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-11 11:00 [Buildroot] pre-built binary packages Marc Murphy
2017-10-11 13:11 ` Thomas Petazzoni
2017-10-11 21:36 ` Henrique Marks
2017-10-11 21:56 ` Thomas Petazzoni [this message]
2017-10-11 22:25 ` Henrique Marks
2017-10-12 15:24 ` Arnout Vandecappelle
2017-10-11 22:16 ` Marc Murphy
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=20171011235642.610fdc3d@windsurf.lan \
--to=thomas.petazzoni@free-electrons.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