Installing proto pc files in /usr/share/pkgconfig?

[Dan Nicholson]

On Mon, Sep 24, 2012 at 8:04 AM, Yaakov (Cygwin/X)
<yselkowitz at users.sourceforge.net> wrote:
> On Mon, 2012-09-24 at 07:15 -0700, Dan Nicholson wrote:
>> On Sep 23, 2012 9:59 PM, "Yaakov (Cygwin/X)" wrote:
>> >
>> > On 2012-09-23 12:35, Matt Turner wrote:
>> >> The proto packages install their pc files in $(libdir)/pkgconfig,
>> >> but this leads to files being installed in /usr/lib32 or /usr/lib64
>> >> when there's nothing ABI specific about them.
>> >>
>> >> Would it be reasonable to install them to $(prefix)/share/pkgconfig instead?
>> >
>> > Absolutely NOT.  If you do this, then they will be picked up when
>> > cross-compiling, adding e.g. -I/usr/include to CFLAGS, which will
>> > then cause the build-system's headers to be used instead of the
>> > cross-host's.
>>
>> Can you explain how this affects cross-compiling?
>
> Unlike /usr/lib/pkgconfig, /usr/share/pkgconfig is meant to be used even
> when cross-compiling.  If you put the *proto.pc in the latter, then
> cross-compile anything which requires *proto, pkg-config will use the
> native proto and do one of two things:

I'm sorry, but I don't think this policy makes sense for cross-compiling.

1. As you demonstrated (and speaking as a pkg-config maintainer),
pkg-config does not treat /usr/share/pkgconfig the way you want it to.
It's mean to be for a multiarch system sharing the same root, not for
a cross-compile scenario where you're trying to minimize pollution
from the host root. pkg-config has no code that guarantee's things in
/usr/share/pkgconfig are cross-compile safe.

2. If you're going to keep using .pc files from the host, then why is
it wrong to use pathways from the host? What other information besides
pathways under /usr would be returned from a .pc file in /usr? Either
pkg-config is telling your compiler to use -I/usr/include or it's
doing it implicitly like your host compiler would. Either way, it
sounds like you want to minimize pollution of the host system to your
cross-build. In that case, why are you using the host .pc files at
all? It sort of sounds like you shouldn't be using the host pkg-config
path at all if you want to guarantee you won't pollute your build
environment.

3. I think making this change doesn't actually affect your situation.
Either way you need to build and install the package supplying the .pc
file to your cross-root. Suppose the proto packages stay in
/usr/lib/pkgconfig and you avoid them for your setup. You still need
to build those packages with your cross-root paths. If these proto
packages start showing up in /usr/share/pkgconfig, you still need to
build the packages for your new root so the .pc files are found
earlier in the path than /usr/share/pkgconfig. I imagine you're
building all the proto packages now for your cross setup, right? How
does change anything?

> There is also the matter of xproto and xtrans not being truly
> cross-platform (e.g. NARROWPROTO and FUNCPROTO in Xfuncproto.h), so each
> platform anyway needs their own copy.

Obviously, if a proto package isn't truly arch-independent, it
wouldn't get moved over. The vast majority are completely
arch-independent.

--
Dan