[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: configuring libltdl

From: Bob Friesenhahn
Subject: Re: configuring libltdl
Date: Tue, 25 Nov 2003 09:28:33 -0600 (CST)

On Tue, 25 Nov 2003, Gary V. Vaughan wrote:

> Hash: SHA1
> Bob Friesenhahn wrote:
> | On Mon, 24 Nov 2003, Gary V. Vaughan wrote:
> |
> | There are a number of issues that would have to be handled in order to
> | properly integrate libltdl configure/build into the dependent
> | package's configure/build.  Historically, the libltdl directory has
> | been a fully-populated stand-alone directory.
> Actually, I already broke that by adding ACLOCAL_AMFLAGS = -I ../m4
> to libltdl/ :-(

For shame! :-)

> | Currently libltdl includes config.h like this:
> |
> | #  include <config.h>
> | #endif
> |
> | In order to use some configuration header name, or path, other than
> | <config.h>, the user needs to manually edit ltdl.c.  That is what I
> | have had to do with my packages.
> |
> | It would be much better if there was a way to specify the package
> | configuration file name for ltdl.c to use.  For example
> |
> | #if defined(LIBLTDL_CONFIG_H)
> | #  include LIBLTDL_CONFIG_H
> | #else
> | #  include <config.h>
> | #endif
> | #endif
> |
> | Some means would need to be found for AC_LIB_LTDL to export the
> | package's configuration header name the same way that HAVE_CONFIG_H is
> | currently defined.  The definition would need to appear on the
> | compiler command line.
> I don't like this.  If libltdl is sharing a configure script, it should also
> share config.h.  Why did you want to generate two config.h's?

The reason for the proposed approach is because packages often use a
different name for their configure header than the default "config.h".
The most common reason for doing this is to avoid the possibility that
the wrong header will be used in complex build environments.
Regardless of whether the content of the libltdl subdirectory is
changed, some provision should be made to tell ltdl.c which
configuration header to include so that ltdl.c doesn't need to be
manually edited.

> | I am not sure what do to regarding the legacy expectation that the
> | files in the libltdl subdirectory are prepared like a full-fledged
> | stand-alone application.
> We fixup libtoolize --force to upgrade to the new improved integrated
> configuration :-)

Libtoolize would have to be pretty smart since the package's and/or would need to be updated.  It is only
a couple lines of code, but it may be difficult to reliably implement.

> | The only files that would need to appear in the libltdl subdirectory
> | are COPYING.LIB, ltdl.h, ltdl.c,, and  There
> | is an issue with using since the user doesn't currently
> | need to use Automake in order to configure and use libltdl.
> Good point. As long as we ship (and libtoolize --ltdl installs
> only if $configure_ac has no reference to AM_INIT_AUTOMAKE) that
> should satisfy the autoconf/libtool only audience...

Right.  The file should depend only on substititions
requested by AC_LIB_LTDL.

Bob Friesenhahn

reply via email to

[Prev in Thread] Current Thread [Next in Thread]