Re: where libltdl will be libtoolized

[Bob Friesenhahn]

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!!!

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.

> 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". 
It is a bad idea to assume where the libltdl files will be located. 
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.

> 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.

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

> I like the former better for several reasons:
> - better forward compatibility from 1.5 (maybe)
> - supposedly less trouble when within a larger collection of
>  sub-packages.
> - People much rather like to bury autotools in some directory
>  structure whose top they decide and the innards they could care less.
>
> Anybody know packages using libltdl with a different strategy already
> (which would then conflict)?
>
> So, OK to apply this patch?
>
> 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?

Bob
======================================
Bob Friesenhahn
address@hidden
http://www.simplesystems.org/users/bfriesen