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
