[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH 1/3] maint: rename `libltdl/config' directory to standard `bu
Gary V. Vaughan
Re: [PATCH 1/3] maint: rename `libltdl/config' directory to standard `build-aux'.
Sat, 5 Nov 2011 19:20:14 +0700
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
>> recommendation, and if you ignore that, nothing will actually break, you will
>> just get duplicate copies of libltdl's build-aux files (compile,
>> 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
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
> 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
Expect another few sets of patches before the resubmission.
Gary V. Vaughan (gary AT gnu DOT org)
Re: [PATCH 1/3] maint: rename `libltdl/config' directory to standard `build-aux'., Eric Blake, 2011/11/01
Re: [PATCH 1/3] maint: rename `libltdl/config' directory to standard `build-aux'., Bob Friesenhahn, 2011/11/01
- Re: [PATCH 1/3] maint: rename `libltdl/config' directory to standard `build-aux'., (continued)