Re: TODO

[Jacob Meuser]

On Sat, Nov 13, 2004 at 10:21:19AM +0100, Ralf Corsepius wrote:
> On Fri, 2004-11-12 at 23:02 -0800, Jacob Meuser wrote:
> > On Sat, Nov 13, 2004 at 04:27:28AM +0100, Ralf Corsepius wrote:
> > > On Fri, 2004-11-12 at 14:31 -0800, Jacob Meuser wrote:
> > > > On Fri, Nov 12, 2004 at 03:33:02PM -0600, Albert Chin wrote:
> > > > > On Fri, Nov 12, 2004 at 11:20:13AM +0000, Gary V. Vaughan wrote:
> > > > > > Albert Chin wrote:
> > > > > > > On Wed, Nov 10, 2004 at 03:43:48PM +0000, Scott James Remnant 
> > > > > > > wrote:
> > > > > > > 
> > > > > > >>On Tue, 2004-11-09 at 14:24 +0000, Gary V. Vaughan wrote:
> > > > > > >>
> > > > > > >>
> > > > > > >>>6.  Absorb the functionality of the aberration called 
> > > > > > >>>pkg-config. Libtool
> > > 
> > > > > > >>>    already has all the information it needs, we just need to 
> > > > > > >>> teach it (or
> > > > > > >>>    maybe a subsidiary script) to spit out link flags after 
> > > > > > >>> poking around
> > > > > > >>>    in a dependency chain of .la files.
> > > > > > >>
> > > > > > >>There's actually a couple of things pkg-config does that Libtool 
> > > > > > >>doesn't
> > > > > > >>currently do.  pkg-config's main job can be summed up simply as 
> > > > > > >>enabling
> > > > > > >>parallel-installed -dev packages.
> > > > 
> > > > since when does libtool care about CFLAGS
> > > It hardly can avoid doing so if wanting to support multilibs.
> > 
> > of course, it cares about _some_ CFLAGS at build time.  it does not
> > care about where the headers are going to be installed though, or what
> > CPPFLAGS need to be set either ... functionality you do get from
> > pkg-config.
> Well, current libtool does not support multilibs.
> 
> If multilibs should ever be able to support them, I'd expect libtool
> having to examine the whole command being used, comprising CFLAGS and
> CPPFLAGS (There exist targets where multilib variants are being
> triggered by preprocessor flags)

but does it care about where the package is going to install it's
headers?

> > > >  or package versions?
> > > It doesn't care about package versions, but it has to care about library
> > > versions and paths to libraries.
> > 
> > again, functionality provided by pkg-config.
> No. Like libtool, pkg-config only covers some parts of the whole
> picture. *.la's contain information pkg-config has not notion about,

yes

> and
> *.pc's can contain information libtool has no notion about.

yes

they serve two distinct purposes.

> (libtool-*.la's contain linker/library specific info. *.pc's basically
> are more or less a poor-man's registry/database and can contain
> arbitrary information).

yes, two distinct purposes.

> > I am contesting the claim "Libtool already has all the information
> > it needs".
> Agreed, but neither has pkg-config.

huh?

> It's just that their functionality
> intersects and partially conflicts.

how?

pkg-config is used to give basic information about installed packages.

libtool is used to build libraries.

pkg-config is used in configure scripts.

libtool is used in Makefiles.

yes, it's possible to use constructs like

foo.so: foo.o
        ${CC} ${LDFLAGS} -o foo.so foo.o `pkg-config bar --libs`

in Makefiles, but this is not overlap in a conflicting way.  libtool
isn't even being used there.  and if CC is libtool, then if it cannot
handle that command, then, well, libtool is the abberation, because
then it's not doing what it is supposed to do.  libtool is supposed to
make building libraries/shared objects easier.

now, could you please tell me where pkg-config conflicts with libtool,
or why pkg-config is an "aberration", or why the libtool codebase
should be bloated to provide functionality already provided by
another commonly use package?

> Ralf
> 

-- 
<address@hidden>