On Wed, 2 Nov 2011, Gary V. Vaughan wrote:
Did you consider this existing use while developing the plan to rename this
often-shared directory?
Yes I did, and it doesn't seem at all onerous to me if I have gone to all the
trouble of upgrading libtool and re-bootstrapping my project with it to also
amend one line in configure.ac. As it stands, libtoolize will issue an upgrade
recommendation, and if you ignore that, nothing will actually break, you will
just get duplicate copies of libltdl's build-aux files (compile, config.guess,
config.sub, depcomp, install-sh, ltmain.sh and missing) alongside your parent
project's files in ltdl/config.
Gary,
Due to libtool's spotted past, many projects check the 'libtoolized'
files (including libltdl) into their project's source control system,
including rather crippled systems like CVS. Libtool files then become
much more carefully managed than autoconf or automake generated files
because libtool was historically more fragile. A change to the
libltdl footprint then requires adding/removing/renaming directories.
Likewise, it has become common for various OS distributions to patch
package's bundled libtool files (which include non-libtool files like
config.guess) as part of the procedure to build a package for that OS
distribution. Moving the files increases effort and churn since the
patches need to be re-generated and re-distributed.
If an OS port is completely re-autotooling the packages (as some OS
distributions mandate), then more effort is required if non-autotool
files in the package now need to be patched to work with the specific
libtool version used.
If a package does not check generated autotools files into its source
repository then each person using the source repository needs to
autotool the package, and changing the path makes the package
libtool-version sensitive so that only newer (or older) versions will
work. It is rather inconvenient for developers to maintain several
installed libtool versions in order to successfully autotool packages.
I am not saying that the effort is insurmountable but it is perhaps
more effort to the world at large than your are imagining.
However, what did you think of my plan to adopt a gnulib inspired cruft
removal warning and tidy up process (the second paragraph in this post:
http://lists.gnu.org/archive/html/libtool-patches/2011-11/msg00002.html)? If
you don't object, in that vein I'll add code to libtoolize (scheduled for
removal in 2013) which copies $pkgdatadir/build-aux contents to the existing
ltdl/config you've specified in the parent configure.ac AC_CONFIG_AUX_DIR
declaration...
My project (and the derived ImageMagick) are among the very few which
would be impacted by this proposal since its non-recursive build is
including the libltdl bits from Makefile.am like:
include ltdl/Makefile.inc
This is another case of changing a documented external interface. The
impact is surely much smaller than moving the 'config' files. Google
shows very few packages using this approach.
The deprecation detection logic does not seem fully robust since there
is no standard extension for Automake include files and file naming
other than *.mk and Makefile.am might be used.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer, http://www.GraphicsMagick.org/