Re: [PATCH 1/3] maint: rename `libltdl/config' directory to standard `build-aux'.
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/msg2.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/
Re: [PATCH 1/3] maint: rename `libltdl/config' directory to standard `build-aux'.
On Wednesday 02 November 2011, Gary V wrote: > Hi Stefano, > > On 1 Nov 2011, at 21:57, Stefano Lattarini wrote: > > Hi Gary, hope you won't mind few nits from an outsider ... > > Absolutely not, any and all feedback is always extremely welcome. Thank you. > > > On Tuesday 01 November 2011, Gary V wrote: > > >> # The timestamps on these files must be preserved carefully so we install, > >> # uninstall and set executable with custom rules here. > >> -auxfiles = $(pkgaux_scripts) config/ltmain.sh > >> +auxdest = build-aux > >> +auxfiles = $(pkgaux_scripts) $(auxdest)/ltmain.sh > >> > > > >> # Everything that gets picked up by aclocal is automatically distributed, > >> # this is the list of macro files we install on the user's system. > >> -aclocalfiles = m4/argz.m4 m4/libtool.m4 m4/ltdl.m4 m4/ltoptions.m4 \ > >> -m4/ltsugar.m4 m4/ltversion.m4 m4/lt~obsolete.m4 > >> +macrodest = m4 > >> +aclocalfiles = $(macrodest)/argz.m4 \ > >> +$(macrodest)/libtool.m4 \ > >> +$(macrodest)/ltdl.m4 \ > >> +$(macrodest)/ltoptions.m4 \ > >> +$(macrodest)/ltsugar.m4 \ > >> +$(macrodest)/ltversion.m4 \ > >> +$(macrodest)/lt~obsolete.m4 > >> > > Shouldn't this better be done in either a preparatory or follow-up patch? > > > > Ditto for other similar changes. > > I like to make sure the tree is capable of passing `make distcheck' after > every patch, > And this is a very good policy, with which I fully agree. What I meant was: wouldn't be better to introduce the $(auxdest), $(macrodest) and $(ltdldest) in a preparatory patch (with no semantic change), so that the edit to `Makefile.am' done in the present patch patch can be brought down to a minimal change like "auxdest = config" => "auxdest = build-aux"? > and splitting this one into "move directories around" and > "fixup the aftermath" would leave the tree broken in the middle... > This is not what I proposing, not at all! What I was proposing is: 1. in a first, preparatory patch, factor out the names/locations of the directories in proper variables and/or makefile macros; 2. in the "real" patch, move the directories around, leveraging on the previous refactoring to ensure this moving can be done with smaller and more self-contained changes. Sorry if I failed to express myself correctly; I hope I've made my point clearer this time. Regards, Stefano
Re: [PATCH 2/3] maint: rename `libltdl/m4' directory to standard `m4'.
Hi Gary. On Wednesday 02 November 2011, Gary V wrote: > > >> package_revision=`$SHELL $ac_aux_dir/git-version-gen .tarball-version` > >> diff --git a/libltdl/.gitignore b/libltdl/.gitignore > >> index 2f39096..5795dbc 100644 > >> --- a/libltdl/.gitignore > >> +++ b/libltdl/.gitignore > >> @@ -2,5 +2,4 @@ > >> /Makefile.am > >> /argz.h > >> /build-aux > >> +/m4 > >> -/dummy.c > >> -/gnulib.mk > >> > > Shouldn't these last two edits be done in a separate patch? > > No, because I don't want to introduce broken revisions that cannot build > into git history. > I think there's a misunderstanding here. What I meant is: since (as far as I can see) dummy.c and gnulib.mk are not touched/moved by this patch, shouldn't any edit to `.gitignore' that involves them better be done in a separate patch? Or am I missing something? > > Also, > > shouldn't you report the changes to file `libltdl/.gitignore' in > > the ChangeLog entry? > > That's interesting actually. Historically, we have only reported changes > to distributed files in ChangeLog, and have always omitted at least VCS > control files from the log entries. I'm still leaning slightly towards not > introducing ChangeLog noise to describe things that are only important > when you have the full git checkout available, and hence access to git log > and friends if you want to dig this sort of information out -- BUT I could > easily be persuaded to change my mind if you have a good argument for the > advantage of putting this stuff into the git log entry, which would then > eventually be put into the generated ChangeLog file... > I have no strong opinion on the matter (even if I personally prefer, when writing a ChangeLog entry, to mention any non-generated, version-controlled file that gets modified, whther distributed or not). I just wanted to make sure the lack of `.gitignore' mention in the ChangeLog wasn't the result of an overlloking. Regards, Stefano
