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