pkg-config and cross-compiling redux

[Guido Draheim]

Guido Draheim wrote:
> 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-
> 

-- 
-- guido                                  http://google.de/search?q=guidod
GCS/E/S/P C++/++++$ ULHS L++w- N++@ d(+-) s+a- r+@>+++ y++ 5++X- (geekcode)