[Top][All Lists]

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

Re: where libltdl will be libtoolized

From: Ralf Wildenhues
Subject: Re: where libltdl will be libtoolized
Date: Sat, 20 Nov 2004 08:36:51 +0100
User-agent: Mutt/1.5.6+20040722i

* Bob Friesenhahn wrote on Fri, Nov 19, 2004 at 09:35:19PM CET:
> On Fri, 19 Nov 2004, Ralf Wildenhues wrote:
> >Current state of libtldl branch-2-0 is inconsistent:
> > libtoolize --ltdl=some/sub/dir
> >
> >will not work.  The include paths in ltdl.h
> >| ltdl.h:#include <libltdl/lt_system.h>
> >| ltdl.h:#include <libltdl/lt_error.h>
> >| ltdl.h:#include <libltdl/lt_dlloader.h>
> Oh, dear!!!

So you haven't tried this out in your package yet, right? ;->

> The package I maintain puts libltdl files in the directory 'ltdl' 
> rather than 'libltdl' and I expect to keep things that way (we still 
> use CVS).  It seems wrong for libltdl files to make assumptions 
> regarding the directory they reside in.

How unfortunate.

We have to make a choice here, both possibilities have drawbacks:
If you keep a flat structure, people using an installed libltdl will
have to use -I$(includedir)/libltdl, plus we risk filename collision
(people don't expect arbitrary files beginning with `lt' to conflict
with libltdl).

Would a missing feature in the SCM you use be the only deterrent?
I mean, even in CVS, since the jump from libtool-1.5 to 2.0 a rather
large one (and ltdl-internal file reorganizations have been rather
large as well), I don't think one would lose too much information by
doing { cvs rm ltdl; cvs add libltdl }.

But hey, I'm not the one to make the call.  I'd much rather like to
see branch-2-0 libltdl tested in a big package than not. :-)

> >and libltdl/'s
> >| AM_CPPFLAGS             = -I$(top_builddir) -I$(top_srcdir)
> >
> >will conflict in a package which uses libltdl.
> Yes, and it will not work if libltdl files are under "foo/libltdl". 

Well, given my changes, "foo/libltdl" will work.

> It is a bad idea to assume where the libltdl files will be located. 

In general: ACK.

> If the libltdl build needs to know, and it can't find out for itself, 
> then the "user" ( should be required to specify where the 
> libltdl files reside.

Yes.  Unfortunately, you also have to think about the case where libltdl
is installed.

> >We have to decide: Either the `libtoolize --ltdl' argument must
> >end in `libltdl', or we need to provide a flat directory structure.
> >(Note that this stems from the requirement to be able to either use
> >an installed libltdl or a package-internal one, with the repective 
> >other
> >one absent).
> A flat directory structure (as we had before) sounds good to me.  I do 
> not plan to actually use libltdl's to build libltdl since 
> that would require that the build is recursive and my package does not 
> use a recursive build anymore.  I do/did plan to see if libltdl's 
> files can be adapted to serve either purpose (supporting 
> non-recursive build via Automake includes) but I have not had time for 
> that yet.

That'd be great.

> Libltdl's new complex build scheme has been worrying me.

Let's see if we can help that.

> >Doesn't the config.h header still pose problems?  I think not but am
> >not so sure.
> I see code in argz.c that looks like it could be a problem.  Maybe it 
> wasn't updated the same way as other source files?

I fail to see this.  Can you be more specific?


reply via email to

[Prev in Thread] Current Thread [Next in Thread]