[PATCH] util-macros: Addition of a meta data file xorg-macros.pc.in used by XORG_INSTALL

[Mark Kettenis]

> From: Mikhail Gusarov <dottedmag at dottedmag.net>
> Date: Thu, 03 Dec 2009 07:42:24 +0600
> 
> Twas brillig at 17:36:45 02.12.2009 UTC-08 when cworth at cworth.org did gyre =
> and gimble:
> 
>  CW> I hope I don't come across as incredibly dense, but I still don't
>  CW> understand why this .pc file must be installed in datadir not
>  CW> libdir.
> 
> During cross-compilation brain-damaged stuff like libxtrans just will
> not be picked up by compiler unless various pereversions are
> applied. Given this, xtrans.pc need to be installed to /usr/share, and
> hence there is no problem to install rest of arch-independent stuff to
> /usr/share.

Sorry, I must be missing something.  Since when do compilers look in
/usr/share?

And I suspect this applies only to a particular way of doing
cross-compilation.  Just look at the madness in the GDB configure
scripts to see infrastructure for half a dozen other ways people do
cross-compilations.

>  >> So far we have one tool (cross-compile) that relies on this
>  >> architecture.
> 
>  CW> How would cross-compiling not work if xorg-macros.pc were installed in
>  CW> libdir? Maybe this is the point I'm missing.
> 
> Include list for cross-compilation does not include /usr/lib, it instead
> includes /usr/$arch/lib. All libraries need to be installed to
> /usr/$arch/lib anyway to be usable for cross-compilation, but headers
> and stuff like macros and source code do not.

Isn't /usr/$arch just another $PREFIX?  So currently .pc files would
end up in /usr/$arch/lib where they would be picked up just fine if
you set the proper environment variables.  Corss-compilation is the
special case here.  It's perfectly acceptable to ask people to do a
bit of more work in that case.  Much more acceptable than imposing the
same burden on the majority of people doing native builds.