Akim Demaille and I suggested earlier to move autoconf-lib-link to autoconf. Gary V. Vaughan suggests moving them to libtool instead. Actually this small package consists of three things: A) The autoconf macros and their associated documentation. B) The config.rpath file which contains the platform dependencies. C) A testsuite that tests the combination of (A), (B), and libtool. (A) fits best into autoconf, because 1. The autoconf-lib-link macros are primarily made for linking with _any_ kind of shared or static library. libtool libraries (.la) are supported as a special case, with special benefits. 2. This is where users look for it, as Harlan Stenn pointed out. 3. The documentation of the macros fits in 50 lines. If you were to put it into libtool's documentation, with its complexities of versioning, dlopening, --mode switches, etc. etc., users would get lost. (B) doesn't fit into autoconf, because autoconf is not meant to install files in AUX_DIR - that's automake's job. It can also fit in libtool because the values that config.rpath outputs are a subset of those used by libtool. (C), the testsuite, fits best into libtool because it's libtool which is the most fragile - due to its complexity - and therefore the most likely to break the combination of (A) + (B) + libtool on particular platforms. Put another way: The macros (A) change rarely in ways that would make them break on particular platforms; therefore simple testing is sufficient for them. However libtool needs more thorough testing because it has the biggest wealth of platform dependent parameters (hardcode_libdir_spec etc.) So my proposal is: * Move (A) to autoconf, * Move (B) to be maintained by the libtool people, but distribute it through automake (like automake also distributes 'mkinstalldirs', 'ylwrap', 'elisp-comp' etc.), Alternatively, distribute it through the same channel as config.guess and config.sub, namely either a regular update on ftp.gnu.org or a reference to the savannah-hosted CVS. * Move (C) to libtool. Gary wrote: > The problem with maintaining them in autoconf is that they will always be a > step behind the equivalent code in libtool, and neither would get the others > bug fixes reliably. If you want speedy releases, then distribute config.rpath like config.guess and config.sub. For my part, I think it's OK for a package to distribute a slightly out-of-date config.rpath, because those few people who need the adaptations for the newest platforms can simply download and replace this single file. The situation is not like libtool.m4, which - once replaced with a newer version - requires runs of autoconf, autoheader etc. in order to be functional. In the past, I have updated config.rpath _reliably_ from libtool releases. In the other direction (config.rpath -> libtool) there were communication problems that looked like being due to the structure, size or motivation of the libtool team; I can't tell exactly. Bruno