Re: macros for rpath support

[Bruno Haible]

Akim Demaille writes:
> Bruno> The variables determined by config.rpath are a subset of those
> Bruno> determined by libtool.m4. Therefore config.rpath should be
> Bruno> updated according to modifications made in official libtool
> Bruno> releases. (But it doesn't hurt verifying the settings using the
> Bruno> rpathcfg.sh script.)
> 
> So, am I reading Libtool would be a better host for this macro?

I don't think so, for two reasons:

1) The focus of libtool is _creating_ shared libraries. If the macros
were added to libtool instead of autoconf, developers who want to use
libintl or libz or libxml would be told to install a 5 MB package with
200 KB of documentation, just for the invocation of one macro.

Furthermore, the current direction of libtool is moving into
complexity, with support for dlpreopen and libltdl; it just doesn't
feel like the right place for a simple macro.

2) The scope of AC_LIB_LINKFLAGS is to support both libraries built
with libtool and libraries built _without_ libtool.

> Bruno> Yes, there are certainly people who don't want to use
> Bruno> gettextize and instead do everything by hand, at their own
> Bruno> risks. For them it is useful to have the *.m4 files in a
> Bruno> canonical location.
> 
> So we still face the problem I was referring to: aclocal will bring
> them in, and Gettext's version will be overriden.  But I'm OK with
> taking this risk.

Me too; users can easily avoid the risk by using gettextize or (soon)
autopoint.

> For instance, m4_include could require the #serial of the file, and
> then autoreconf --install would pick the most appropriate file.

This has too many pitfalls. (In particular, it creates problems when a
fork occurs and the #serial numbers diverge in an unsynchronized
manner.) Please stay away from this. It's better to decide which file
to include, purely based on the location of the file.

Bruno