Sat Nov 22 22:51:33 EET 2003

Sorry for coming in late on the topic, I wasn't aware of discussions here
and I had been sending discussions and patches to Havoc Pennington as he
is listed as pkg-config maintainer. That should be fixed in the README of
pkgconfig I'd say. Anyway...

> There's a long discussion in:
> 
> http://pdx.freedesktop.org/cgi-bin/bugzilla/show_bug.cgi?id=130
> 
> Between Rüdiger Kuhlmann and me about enhancing pkg-config for cross
> compilation. I'd appreciate it if those interested in the subject
> would read the bug report and comment (here perhaps, since the bug
> report is already reaching bugzilla.mozilla.org proportions.)
> 
> To summarize briefly, some of the proposals that are made there
> are:
> 
>  - Make pkgconfig.m4 use AC_PATH_TOOL so it finds <host>-pkg-config 
>    first.

I have been sending a patch for that as well - it is really a good
macro as it automatically looks for <host>-pkg-config. There is only
one catch: it does not exist in autoconf 2.1x, this is the newer
breed only. Still one may argue WTF does still use an autoconf being
four years old but you might be embarressed to hear that it is still
widely practiced since there are some incompatiblities in the sense
that autoconf 2.5x is more strict and people do not have time or
expertise to fix their configure.in scripts.

Therefore, this change has a common consensus after one clarification:
    do we put autoconf 2.5x as prequisite to work with pkg-config ?
That's political a question as there _might_ be people who have added
some pkg-config support to an old old project w/o fixing and making
it ready for 2.5x. They would be forced to do so with that change.

> 
>  - When pkg-config is invoked as <host>-pkg-config, have it extract
>    the <host> part and substitute it for occurrences of $HOST in
>    $PKG_CONFIG_LIBDIR. 

Uhhh, I like that! Even that one has to show me working code as for
its useful, I do doubt very much there are easy pc files getting a
benefit from it. The pkg-config patch can be done quickly, so one
can just have try and see.

> 
>  - Add a $PKG_CONFIG_CROSS_LIBDIR variable to allow configuration
>    of cross compilation as above while not disturbing native 
>    builds.

Pah! I know a lot of corners in libtool support that would need
some cross libdir support as well. Without that it would be more
or less useless to add it here. We better meet on that topic on
the libtool ML again, shall we.

> 
>  - Add $PKG_CONFIG_DESTDIR ($PKG_CONFIG_CROSS_DESTDIR) variables
>    with subtitution as above that would set a $_destdir variable.
>    This would allow .pc files to be written so they work either
>    on the host or target system.

just again. There are various problems in the sense of canadian
cross that makes your mind silly - in a project, which parts need
to be runnable/linkable on the compile host and which parts are
needed only in the target system and `finished` up blindly.

> 
> (These proposals are filtered through my personal preferences;
> Rüdiger proposed somewhat different forms that amount to basically
> the same thing)
> 

After looking into things I came to the conclusion that it is
much better to keep the old m4 ac macro and simply go for a new
m4 ac macro and in its own file pkgconfig.m4 being installed.
That new macro might take the same call synopsis as the old one
so it is easy to change over projects from old macro to the new
macro. The new macro may be spiced up with a lot of things and
take benefit from the autoconf 2.5x infrastructure in large
chunks. WDYT?

cheers,
-- guido                                http://AC-Archive.sf.net
GCS/E/S/P C++/++++$ ULHS L++w- N++@ d(+-) s+a- r+@>+++ y++ 5++X-