Re: where libltdl will be libtoolized

[Ralf Wildenhues]

* 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/Makefile.am'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" (configure.ac) 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 Makefile.am 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 
> Makefile.am 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?

Regards,
Ralf