bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 7/7] libposix: use git-version-gen for version numbering


From: Gary V. Vaughan
Subject: Re: [PATCH 7/7] libposix: use git-version-gen for version numbering
Date: Wed, 13 Oct 2010 17:18:39 +0700

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 (address@hidden)

Attachment: PGP.sig
Description: This is a digitally signed message part


reply via email to

[Prev in Thread] Current Thread [Next in Thread]