[oe] binconfig.bbclass breaks packages QA

[Richard Purdie]

On Fri, 2008-03-28 at 13:02 +0100, Stanislav Brabec wrote:
> It happens most often with gpg-error-config. It is often embedded to .pc
> files, but it has no .pc file. Adding .pc file will not fix the problem,
> as configure.in checks for gpg-error-config, not for gpg-error.pc. The
> second most problematic is cups-config. Other packages are less often
> used, or they have its own .pc file, which is preferred in new projects.
> Failed projects are for example libgnomecups, gnumeric.

The projects using these will need updates too, this is usually just a
case of adding a line to the Requires field in the .pc (if the lib is
optional there is slightly more work than that). Hopefully we'll be able
to convince the upstream sources to change to pkg-config so the patches
will disappear over time.

> Imagine situation, where all mangling is removed from all tools and only
> gcc will do the mangling internally. foo-config will return
> -I/usr/include/foo, pkg-config will embed -I/usr/include/foo, make will
> call gcc $CFLAGS -I/usr/include/foo. gcc will search in
> sysroot/usr/include/foo and everything should work then.

I can envisage this, its just a *massive* change from the current
behaviour and nobody else is doing this. Applications and autoconf don't
work with this in mind.

> Looking at gcc Bugzilla, this problem affects all toolchains authors.
> 
> Actually, changing OE specific gcc patch to prepend search path with
> system path instead of ICE would work-around it as well.
> 
> I can imagine small patch doing the same more cleanly:
> implement new switches, e. g. --sysroot-all-I --sysroot-all-L.
> 
> Then change add_sysroot_to_chain() to mangle all -I paths, not only
> those in form -I =.

Its a nice idea but doing something like this is outside the scope of
OE. By all means experiment if you want, OE's metadata provides an ideal
testing ground for that but I don't think its something OE will be
switching to any time soon.

Regards,

Richard