Re: [PATCH 1/3] maint: rename `libltdl/config' directory to standard `build-aux'.

[Gary V. Vaughan]

Hi Bob,

Thanks again for the sanity check.  Sorry for my late response; my internet 
access is very spotty at the moment.

On 2 Nov 2011, at 21:12, Bob Friesenhahn wrote:
> 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.
> 
> 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.

I think it would be a terrible idea to try and hold the rationalisation and 
canonicalisation of the directory layout of future libtool releases to ransom 
because of that!  Besides, anyone that chooses to continue using CVS and the 
like, is almost certainly going to be similarly happy sticking with whatever 
old version of libtool they checked in to their tree.

> 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.

Again, in that case, stick with the particular release of Libtool you are using.

> 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.

The logical extension of that argument is that I shouldn't refactor anything, 
rename any variables or otherwise make an effort to clean things up too much, 
in case some users insist on reautotooling a package with a different set of 
autotools than the ones the release was tested on.

> 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.

No one is forcing packages to upgrade.  If the feature set and/or bug fixes in 
the a given release of Libtool are not compelling enough to make upgrading 
worthwhile, then individual package managers can choose to hold back and use an 
earlier release.  If a release manager is going to bootstrap a whole 
distribution's worth of software with his (or his managers') favourite 
selection of autotool versions with no regard for the impedance mismatch with 
what revisions each package maintainer used to roll the release, then they will 
have a LOT more trouble on their hands than setting up a series of parallel 
autotools installs to do their job correctly (at work, we tried bootstrapping 
everything with our favourite selection of patched up autotools for a time... 
but an awful lot of weird bugs went away when we started paying attention to 
bootstrapping things with the right versions of autotools).

>> 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.

I have a better idea for a reimagining of this patch series that I think you 
will find more palatable... so I'll rescind this submission (all 3 of the 
patches I posted on the same day as this one) and rearrange my patch queue to 
enable that.

Expect another few sets of patches before the resubmission.

Cheers,
-- 
Gary V. Vaughan (gary AT gnu DOT org)