[Buildroot] Installation of package files in staging and target
Yann E. MORIN
yann.morin.1998 at anciens.enib.fr
Tue Jul 12 17:39:20 UTC 2011
Quotient, Thomas, All,
On Tuesday 12 July 2011 17:23:15 Quotient Remainder wrote:
> On Tue, 2011-07-12 at 13:51 +0200, Thomas Petazzoni wrote:
> > Le Tue, 12 Jul 2011 11:55:12 +0100,
> > Quotient Remainder <quotientvremainder at gmail.com> a écrit :
> >
> > > I'm a little behind in tracking the changes with toolchain movements
> > > from a few months back but I was of the understanding that the current
> > > install scheme still allows the staging directory to be treated as a
> > > kind of mini SDK and so if I build a system using Buildroot I can tar
> > > up the staging dir and give it to application developers as an
> > > interface. Is this still the case? If so, wouldn't putting
> > > executable programs into the staging dir be a bad thing?
> >
> > Why would it be bad ? The binaries for the target are not inside
> > host/usr/bin, but inside host/usr/<tuple>/sysroot/usr/bin, so even if
> > the user adds host/usr/bin to its path to get access to the SDK, the
> > target binaries won't be visible.
> >
> > It's true however that this would enlarge the size of the SDK.
>
> "Bad" isn't the right word; I shouldn't have used it.
> It wasn't that they'd end up in the host's path that was my concern.
> My thinking was that the binaries don't belong in an SDK since all we'd
> need in it are header files and libraries so applications could be built
> and linked with them.
I see your point. But as we create the target dir as a cleaned-up copy of
staging, then we could create an sdk dir as a cleaned-up copy of
staging as well, except using a different way of cleaning up;
* target/ is a carefuly-crafted copy, minus:
includes and static libs
doc and man and whatnot
pkg-config stuff
and all other stuff irrelevant to running
* sdk/ is a carefuly-crafted copy of staging, including:
includes, shared and static libs
pkg-config stuff
?...
That way, it becomes much easier to install packages. That may even simplify
the package removal later (if we are careful at install time). And as target/
and sdk/ are created at the end, we can more easily ensure what we keep/trash
when doing the copy.
> I suppose it comes down to clarifying what the purpose of STAGING_DIR
> actually is.
Granted. Supposing that we go for a single-step install into staging, and
doing the copy to target/ and sdk/ right at the end, here how it would go.
A bit of pre-requisite are needed here; for example, difference between
--prefix and DESTDIR is expected to be known; ditto $(O):
* packages are installed with DESTDIR=$(O)/staging
- exception made for bootloaders, and potentially kernel, which
install directly in $(O)/images (although I am realy not a big
fan, but that's personal taste)
* After all packages are installed:
+ $(O)/staging is copied to $(O)/target, and the copy is cleaned-up
+ $(O)/staging is copied to $(O)/sdk, and the copy is cleaned-up
* $(O)/target is used as input to generate the images:
+ images are installed in $(O)/images
- file system image(s)
- potentially, kernel image
So, we could even have four top-level make rules:
o images: populate $(O)/images (the default, as today)
o target: populate $(O)/target
o sdk: populate $(O)/sdk
o staging: populate $(O)/staging (aka build and install all packages)
Of course, with the required dependencies:
images -> target -> staging
sdk -> staging
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. |
'------------------------------^-------^------------------^--------------------'
More information about the buildroot
mailing list