Hallo Bruno, Thanks again for the speedy and thoughtful feedback on this patch series. I'm sorry that I won't have the time to actually apply any of your good advice for at least a couple of weeks, but whatever is still outstanding when I next have discretionary hacking time, I'll apply, retest and resubmit to this list.
On 13 Oct 2010, at 04:20, Bruno Haible wrote: > Gary V. Vaughan wrote: >> git-version-gen itself relies on the presence of .git in the >> current directory. I've made a quick and dirty patch to it >> here to also look in the parent directory... but surely there's >> a nicer way to determine whether the current directory is managed >> by git than this? > > A less hacky patch was posted by Giuseppe Scrivano in > <http://lists.gnu.org/archive/html/bug-gnulib/2010-05/msg00090.html>. > I don't know why that patch was not applied. But I'm not a git expert, > I cannot judge it. Nor me. But that patch is already far nicer than my quick and dirty attempt. >> --- a/libposix/configure.ac >> +++ b/libposix/configure.ac >> @@ -17,6 +22,11 @@ AC_CONFIG_FILES([Makefile lib/Makefile tests/Makefile]) >> AM_INIT_AUTOMAKE([foreign]) >> LT_INIT >> >> +# libtool interface versioning for libposix.la >> +AC_SUBST([LTV_CURRENT], 0) >> +AC_SUBST([LTV_REVISION], 0) >> +AC_SUBST([LTV_AGE], 0) >> + >> AC_PROG_CC >> LIBPOSIX_EARLY >> AM_PROG_CC_C_O > > The libtool interface version IMO does not belong in a configure.ac file. > It can go into Makefile.am, or a separate file. I hadn't really thought about that deeply enough, and was merely putting all the version numbers that might need to be changed at release time close together in the same file... > Rationale: The maintainer is supposed to update these three numbers right > before a release. If it is stored in configure.ac, it takes 10 minutes > to rerun configure and regenerate all Makefiles. This is the thing a > maintainer > needs least when he is preparing a release. If it is stored in Makefile.am, > it takes 5 seconds to regenerate that particular Makefile. > > For libposix, this may not matter because libposix is likely built in > batch mode normally. But nevertheless it's a bad precedent. Agreed. > Lesson learned: Don't abuse configure.ac. > +-------------------------------------------------------------------------------+ > | - Use configure.ac and autoconf macros for determining platform > dependencies. | > | - Use Makefile rules (in Makefile.am files) for creating files. > | > | - Use Makefile.am or a separate file for frequently changing parameters. > | > +-------------------------------------------------------------------------------+ Excellent reasoning and advice, thank you. I will take back to the libtool tree with me too, and no doubt save myself an hour of reconfigure and retest at release time. Cheers, -- Gary V. Vaughan (g...@gnu.org)
PGP.sig
Description: This is a digitally signed message part