Re: pkg-config macro patch

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
> >
> > 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
revision 1.2
date: 2000/07/26 21:20:38;  author: kloczek;  state: Exp;  lines: +12 -12
- updated for 0.5.3.
revision 1.1
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|*e-mail: kloczek rudy mif pg gda pl*

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