libtool-patches
[Top][All Lists]
Advanced

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

Re: [PATCH 1/3] maint: rename `libltdl/config' directory to standard `bu


From: Bob Friesenhahn
Subject: Re: [PATCH 1/3] maint: rename `libltdl/config' directory to standard `build-aux'.
Date: Wed, 2 Nov 2011 09:12:07 -0500 (CDT)
User-agent: Alpine 2.01 (GSO 1266 2009-07-14)

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
address@hidden, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/



reply via email to

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