Re: pkg-config macro patch
- From: Tomasz Kłoczko <kloczek rudy mif pg gda pl>
- To: Owen Taylor <otaylor redhat com>
- Cc: gtk-devel-list gnome org
- Subject: Re: pkg-config macro patch
- Date: Fri, 2 Feb 2001 19:46:36 +0100 (CET)
On 2 Feb 2001, Owen Taylor wrote:
> Tomasz Kłoczko <kloczek rudy mif pg gda pl> writes:
> > On 2 Feb 2001, Havoc Pennington wrote:
> > >
> > > Tomasz Kłoczko <kloczek rudy mif pg gda pl> writes:
> > > > And I have patch (prepared few days ago) which allow compile pkg-config
> > > > with system glib and popt. Both ptches probably can allow complet
> > > > pkg-config in useable form :)
> > >
> > > Why was that needed?
> > Incorrect question. Correct is: why pkg-config must have own copy popt and
> > glib files and why it can't use system installed libraries ? and both
> > patches is correct answer for this qustion :)
> > Very similar qustion can be given for example for ORBit ("ansver" is on
> > http://cvs.pld.org.pl/SOURCES/ORBit-use_system_popt.patch).
> > Also gnome-libs have own copy popt files.
> The answer for pkg-config, is that pkg-config is meant to be a tool
> for building packages. And a tool for building packages that we
> want to be used for everybody.
You want say "pkg-config linked with shared glib and popt cant be tool for
building packages". Sorry but I dont't see this. Fix me if I'm wrong.
> If I have a little time, I'd like to try to convince XFree86, freetype,
> etc to ship pkg-config files, and so forth.
> So, it shouldn't have a bunch of external dependencies.
I don't see any reasons for add this dependences. Ones more .. fix me if
you see any wrong consequences. Patch for ORBit in PLD is used from:
$ cvs log ORBit-use_system_popt.patch
date: 2000/07/26 21:20:38; author: kloczek; state: Exp; lines: +12 -12
- updated for 0.5.3.
date: 2000/03/01 07:37:49; author: kloczek; state: Exp;
- patch for linking agains system popt.
And I don't see any wrong effects. Also patch posted to this list for
pkg-config not hurds *anything* (or still .. fix me if I'm wrong :)
> I don't think building either against the system libraries or the
> included libraries is that great of an idea either - it makes QA
> hard, and the pkg-config statically linked against the included
> packages is only 80k.
What QA ? What if Jeff Johnson (rpm and popt maintainer) will receive or
will discover some importand bug in popt ? Is using shared version popt or
probably (if you still want link statically pkg-config) static but system
installed copy is not best way for fix this king bugs ? Is this allow
separate pkg-config bugs only in stricte pkg-config sources code (and not
also popt and glib code) ? Lets allow fix popt and glib bugs people and
maintainers working on this projects and allow themselve think only about
bugs and developmet pkg-config. If you still want make some separations
look .. popt uses also libc code (?) what about include [g]libc code to
pkg-config source tree ? what with m4, perl, autoconf, automake and many
more tools ? :-) No .. IMHO this is wron way :)
Also next .. autoconf very well handles static linking. Try:
$ LDFLAGS="-static" ./configure; make
in pkg-config tree and you will see static linking pkg-config have complet
support on current autoconf suit (?).
> I agree, by the way, that having gnome-libs / orbit have their
> own copy of popt has turned out to be a mistake.
OK. But IMHO including in pkg-config own copy glib and popt is the the
same class mistake :)
> But I don't see this as being comparable. pkg-config is a self-contained,
> statically linked binary.
Echem .. not :>. Try answer on question: "is pkg-config must be
self-contained tool ?" or if you answer privately "yes" try answer on next
question: "is pkg-config linked with shared popt and glib (or staticaly
but with system installed libraries) hurds pkg-config as self-contained
tool ?". IMHO on both questions if you think you can answer "yes" and
in this point we can stop discuss ;_)
*Ludzie nie mają problemów, tylko sobie sami je stwarzają*
Tomasz Kłoczko, sys adm @zie.pg.gda.pl|*e-mail: kloczek rudy mif pg gda pl*
] [Thread Prev