[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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

Rüdiger Kuhlmann wrote:
--[Guido Draheim]--<guidod-2003- 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

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.

 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)

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]