[xdg-list] pkg-config and cross-compiling redux

[Rüdiger Kuhlmann]

>--[Guido Draheim]--<guidod-2003- at gmx.de>

> 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.

Hmm, if the bug tracker isn't the place to look at first, then I don't
know...

> >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.

Pu-lease. autoconf 2.13 is 4.5 years old. Anybody still using it should
update to 2.5x (better 2.57...) better yesterday than tomorrow.

> >Therefore, this change has a common consensus after one clarification:
> >   do we put autoconf 2.5x as prequisite to work with pkg-config ?

If you ask me: definately yes.

> >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.

And that would be a good thing. autoconf.in's made for 2.13, but processed
with 2.5x are a pretty common source of error. You know that it's
configure.ac nowadays?

> >> - 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.

What's the reason to wait for libtool to fix cross-compilation when we want
to fix cross-compilation for pkg-config? Not doing it will require an update
later for everyone to use when libtool is fixed.

> >> - 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.

See my proposal for that topic.

> >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?

Why not add a new macro with the old meaning for autoconf 2.13, and update
the current macro for 2.57 (that's the version I updated it to in my patch,
because it has been there since ~ a year already)? That way, someone who
really has to use pkg-config for some ancient software package can do it,
while the common folks will just pick up cross-compiling on the fly? As in
optimizing for the most common case?

Btw, it would be really nice if there would be finally something done on
this patch...

-- 
         100 DM =  51  € 13 ¢.
         100  € = 195 DM 58 pf.
  mailto:ruediger at ruediger-kuhlmann.de
    http://www.ruediger-kuhlmann.de/