Re: where libltdl will be libtoolized

[Peter O'Gorman]

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>
>
> and libltdl/Makefile.am's
> | AM_CPPFLAGS             = -I$(top_builddir) -I$(top_srcdir)
>
> will conflict in a package which uses libltdl.
>
> 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).
>
> 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)?

Okay, I have a question or two. Since we already have a configure time check 
 to see if we are using the installed libltdl or the included copy and we 
even #define HAVE_LTDL if we are using an installed copy, can we not simply 
ask people to do:
#if HAVE_LTDL
# include <libltdl/ltdl.h>
#else
# include "ltdl.h"
#endif

and then in our #includes do something similar?

I realize that there is Makefile.am stuff to do too to get the -Iflags 
correct (add a -I$(srcdir) to the AM_CPPFLAGS?), but I don't see why we have 
to restrict developers in the way you propose. Am I missing something? It is 
surely possible to fix it so it works "as advertised" by playing with 
ltdl.m4 and the Makefile.am and .c and .h files in libltdl.

Peter