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

[Guido Draheim]

Rüdiger Kuhlmann wrote:
>>--[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 am looking into readme and webpages for hints to where to send things.
If it's not in there then it goes to the e-mail of the primary maintainer.

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

*g* believe it or not but I keep on having chats with mandrake stu^h^h^h
developers to finally use 2.57 as the default autoconf. It still isn't
even for 9.2 of being current. And indeed, there are signs that some big
projects (no names) do not intend to fix their autoconf'iguration very
soon - some people have begun to backport autoconf macros to the 2.1x
system. In other words, some people will like to be compatible to 2.13.


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

Me too, but it's a political question - you need to make a census
on that, and if there's no strong opposition, well, do the change.

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

:-)=) ... guidod <=> ac-archive

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

the reason is (a) i am not the maintainer and gary is doing stuff
in preparation of 1.6 release (b) i do not have time to make up
patches and invest time to persuade people to take them (i did
that in the past)

overall, it would be nice to help a bit with increasing awareness
of crosscompiling problemspace all around - it's not to the best
here at the moment, ye know.

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

hmmm, good point. I like that one, even tho it means that some people
might get mad at you but you can prompt them with a `shut up` and
stick the renamed 2.13-compatible one down their thr... well anyway,
I just like the idea ;-)


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

the finally something done might be you, hp is a bit short on time,
and so build a patch and promoting it might be just the way to go.
You have one on file? And see, I've done the pkgconfig-selfdecribe
patch and nobody's really interested, so the promotion part might
be more consuming than anything else in the process.

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