[oe] RFC: Staging layout and pkgconfig sysroot support

[Stanislav Brabec]

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 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.).

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).

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.


________________________________________________________________________
Stanislav Brabec
http://www.penguin.cz/~utx/zaurus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gcwrap
Type: application/x-shellscript
Size: 1271 bytes
Desc: 
URL: <http://lists.openembedded.org/pipermail/openembedded-devel/attachments/20070917/9fe1e555/attachment-0004.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gcwrap_test.tar.bz2
Type: application/x-bzip-compressed-tar
Size: 835 bytes
Desc: not available
URL: <http://lists.openembedded.org/pipermail/openembedded-devel/attachments/20070917/9fe1e555/attachment-0005.bin>