help-libidn
[Top][All Lists]
Advanced

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

Re: libidn2: ChangeLog, bootstrap


From: Simon Josefsson
Subject: Re: libidn2: ChangeLog, bootstrap
Date: Wed, 28 Dec 2016 15:38:58 +0100
User-agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/24.4 (gnu/linux)

Tim Ruehsen <address@hidden> writes:

>> Thanks for the hint -- see cfg.mk for how it is done in libidn2, i.e.:
>> 
>> ChangeLog:
>>      git2cl > ChangeLog
>> 
>> tarball:
>>      ! git tag -l $(PACKAGE)-$(VERSION) | grep $(PACKAGE) > /dev/null
>>      $(MAKE) ChangeLog distcheck
>> 
>> The idea is that on 'make release', the ChangeLog is re-generated from
>> git commit logs and will be included in the tarball.  This broke because
>> ChangeLog had been accidentally been committed at some point.
>
> The wget method has the advantage that you don't have to remember 'make 
> release', it is regenerated automatically when you create the tarball (make 
> dist, make distcheck).

True, but does it matter?  I suspect this can be fixed if it is
important too.

> Another advantage is that wget doesn't need get2cl - which might not be 
> available on e.g. Solaris.
> E.g. 'gengetopt' is not available there and it was not possible for me to 
> built it (some auto* stuff was not compatible). That means I can't build 
> libidn2 there at the moment. IMO, such dependencies are a waste of time since 
> they just solve trivial tasks, basically nothing.

Neither git2cl nor gengetopt should be needed for normal users.  If
there is ever any developer who wants to be build libidn2 from git on
solaris, maybe we can reconsider.

> Maybe it is possible to use gnulib's git-to-changelog instead of git2cl ?

Yeah, I would like that.  I recall there being some differences between
them, and that git-to-changelog demanded some particular way to format
git commit logs which aren't always followed.  We should probably still
go with the git-to-changelog approach though.

/Simon

Attachment: signature.asc
Description: PGP signature


reply via email to

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