Re: where libltdl will be libtoolized

[Noah Misch]

On Fri, Nov 19, 2004 at 09:06:14PM +0100, Ralf Wildenhues wrote:
> 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).

You can also create an internal directory structure that mirrors your installed
include structure.  This avoids placing directories of which you have no control
($(srcdir)/..) in the include path.  I did this once (The patch itself is one of
my worst; it changed configure.ac needlessly.  It shows the strategy, though.):

http://lists.gnu.org/archive/html/bug-libtool/2004-10/msg00042.html

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

Agreed, except the second point, which I do not understand.

> Doesn't the config.h header still pose problems?  I think not but am not
> so sure.

I think your patch is fine with regard to config.h.

> --- libltdl/Makefile.am       15 Nov 2004 00:52:00 -0000      1.64.2.1
> +++ libltdl/Makefile.am       19 Nov 2004 19:48:36 -0000
> @@ -27,7 +27,7 @@
>  ACLOCAL_AMFLAGS              = -I m4
>  
>  DEFS                 = -DHAVE_CONFIG_H="<$(CONFIG_H)>" -DLTDL
> -AM_CPPFLAGS          = -I$(top_builddir) -I$(top_srcdir)
> +AM_CPPFLAGS          = -I$(top_builddir) -I$(srcdir)/..
>  AM_LDFLAGS           = -no-undefined
>  VERSION_INFO         = -version-info 6:0:0

If $(srcdir)/../string.h exists, libltdl will pick it up in preference to the
system copy.  Whether he or she would be getting what he or she deserves, I do
not know.  It seems easy to avoid, though.