From: Trent Piepho <tpiepho@impinj.com>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH] core/sdk: generate the SDK tarball ourselves
Date: Mon, 11 Jun 2018 22:10:55 +0000 [thread overview]
Message-ID: <1528755055.28705.139.camel@impinj.com> (raw)
In-Reply-To: <20180611210125.108ff027@windsurf>
On Mon, 2018-06-11 at 21:01 +0200, Thomas Petazzoni wrote:
> Hello,
>
> On Mon, 11 Jun 2018 17:20:57 +0000, Trent Piepho wrote:
>
> > Is the problem with using this tarball apparent? The dockerfile needs
> > to be hand edited on every single build to use the correct path to the
> > SDK.
> >
> > I've already added a "sdk-tar" to my external.mk to do this, but used
> > the tarbomb approach. While annoying for those who extract it in their
> > home dir, it's much easier to use in an automated processes since there
> > is no unknown path name component.
>
> You want to use the --strip-components=1 option of tar, which Buildroot
> is already using when extracting the tarballs of upstream packages into
> the output/build/<package>-<version>/ directories.
Which is great when using GNU tar that has that option. But Docker
does not.
I can make a Docker friendly tarball myself, as I do now. But after
this patch there is no way to do that without also making an unused
non-Docker friendly tarball. Which is pretty costly on VMs with poor
io performance.
Some ideas to avoid this:
1. Make tarball generation a new target instead of "sdk".
2. Make tarball generation the "sdk" target but add another target that
does what "sdk" used to do.
3. Allow the tarball path prefix to be specified in some way, so that
it is easier to inject into an automated process that uses the SDK.
E.g., it can be defined as a constant in the defconfig, or passed from
a higher level to both buildroot when the SDK is made and to whatever
uses the SDK.
next prev parent reply other threads:[~2018-06-11 22:10 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-06-09 21:06 [Buildroot] [PATCH] core/sdk: generate the SDK tarball ourselves Yann E. MORIN
2018-06-09 21:16 ` Yann E. MORIN
2018-06-10 6:03 ` Thomas Petazzoni
2018-06-10 7:47 ` Yann E. MORIN
2018-06-10 21:21 ` Arnout Vandecappelle
2018-06-11 17:20 ` Trent Piepho
2018-06-11 19:01 ` Thomas Petazzoni
2018-06-11 22:10 ` Trent Piepho [this message]
2018-06-12 9:57 ` Thomas Petazzoni
2018-06-12 17:11 ` Trent Piepho
2018-06-12 13:30 ` Arnout Vandecappelle
2018-06-12 17:47 ` Trent Piepho
2018-06-12 18:07 ` Stefan Becker
2018-06-12 19:01 ` Thomas Petazzoni
2018-06-12 19:25 ` Stefan Becker
2018-06-13 8:32 ` Andreas Naumann
2018-06-13 10:12 ` Arnout Vandecappelle
2018-06-13 15:46 ` Andreas Naumann
2018-06-13 9:47 ` Arnout Vandecappelle
2018-06-13 9:57 ` Thomas Petazzoni
2018-06-13 10:03 ` Stefan Becker
2018-06-13 11:58 ` Thomas Petazzoni
2018-06-15 18:27 ` Peter Korsgaard
2018-06-13 7:46 ` Arnout Vandecappelle
2018-06-13 7:59 ` Stefan Becker
2018-06-15 18:12 ` 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=1528755055.28705.139.camel@impinj.com \
--to=tpiepho@impinj.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