[oe] RFC: Staging layout and pkgconfig sysroot support
Richard Purdie
rpurdie at rpsys.net
Tue Sep 18 08:39:11 UTC 2007
On Mon, 2007-09-17 at 22:30 +0200, Stanislav Brabec wrote:
> Richard Purdie wrote:
>
> > I'm interested in people's views on whether this would be a worthwhile
> > change or not? Should we change all staging layouts or leave say native
> > packages as they are?
> >
> > As a first step I will investigate removing some of the hardcoded layout
> > assumptions I've found so far as I think they're good to remove
> > regardless of whether we change staging layout or not. In theory people
> > or distros could maybe then choose their own layout even!
>
> Well, I proposed the systoot some time ago and you opposed with its
> disadvantages.
I was thinking about that when I wrote this email. Someone does need to
argue the opposite case as this is a fundamental change and it needs
discussion. I haven't made my mind up which approach is better to be
honest.
I didn't and don't like the added complexity of multiple lib and bin
directories...
> I tried the second way: Write a compiler wrapper.
>
> Here is my first proof of concept wrapper. Now it hardcodes paths and
> some parts should be a subject of discussion (e. g. -nostdinc). It
> already compiled a small binary+library, but I did not try bootstrap
> with it yet (I don't know how to do a system-wide change of cross-CC
> etc.).
I noticed the first line of the wrapper is:
# Warning: Your local compilation builddir musr not be inside /usr!
which just broke some of my builds since I build in /usr on certain
machines :/.
> Advantages of gcwrap over -sysroot:
> - We can keep existing structure.
> - Save storage while building for more platforms at once.
>
> Advantages of -sysroot over gcwrap:
> - A bit better support (in gcc and libtool but not automake checks).
> - Simpler manipulation with one directory.
>
> There is a particular question, whether overlay parts
> noarch-platform-machine should follow target system structure.
> I think that yes, even if it could break some recipes.
>
> In all cases, I would propose a QA tool causing error of any package
> embedding any staging dir or DESTDIR into any file (except debug info).
Agreed, this is something I suspect the QA people are working towards?
> There is still a lot of stuff, which don't support any of mentioned
> concepts at all (e. g. AC_CHECK_FILE, AC_CHECK_PATH checks) and could
> cause bad assumption (see fileutils locate script). In these cases, one
> must provide a correct ac_ value to configure script or even patch the
> package.
In an ideal world, we'd rewrite these macros and have our own safer
versions even if they were to error out...
Cheers,
Richard
More information about the Openembedded-devel
mailing list