Re: where libltdl will be libtoolized

[Bob Friesenhahn]

On Sat, 20 Nov 2004, Ralf Wildenhues wrote:

> * 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? ;->

Nope.  Until maybe a month ago, libtool 2.0 was way too unstable to 
actually use.  It seems to be mostly shored up now.

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

Yes.  The package I maintain uses CVS for actual version and release 
control.  The 'ltdl' path is in the CVSROOT/modules file which is 
shared by many releases and branches, so the path is very difficult to 
change.  However, it could be accomplished by using the path 
'ltdl/libltdl', which seems pretty funky, but workable.

Libltdl has been documented since the beginning of libltdl time to 
work in an arbitrary source directory.

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

Prefixing files with lt_ seems plenty safe to me.

Since up to now, ltdl.h has been installed directly in the top include 
directory, there is risk of leaving the old version behind, or having 
the old version used by accident.

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

Only the ability to support existing release branches. :-(

There are work-arounds, but they may impact existing CVS checkouts.

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

What is the minimal version of Automake which we will require in order 
to build libltdl?  Is it a dinosaur like 1.4, or a more recent vintage 
which supports files in subdirectories?

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

argz.c is unusual in that it includes this code block:

/* Provide our wierdo HAVE_CONFIG_H rvalue for other clients.  */
#if !defined(LTDL) && defined(HAVE_CONFIG_H)
#  define HAVE_CONFIG_H <config.h>
#endif

The lt__alloc.c also mentions HAVE_CONFIG_H but it does not include 
the extra block of code.  It is not clear to me why the files are 
different in this regard.

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