automake
[Top][All Lists]
Advanced

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

Re: targets to handle gnu dist procedures?


From: Tom Howard
Subject: Re: targets to handle gnu dist procedures?
Date: Thu, 03 Mar 2005 11:57:08 +1100
User-agent: Mozilla Thunderbird 1.0 (Windows/20041206)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

Alexandre Duret-Lutz wrote:
> Actually the release procedure is so different for each package
> that it seems impossible to automatize.
> 
> In the case of the Automake package, for instance, the release
> procedure (after you have modified the version number and
> regenerated dependent files) is
> 
>    1) distcheck
>    2) commit to CVS, and tag the release
>    3) upload to gnu.org and sourceware.
> 
> The version bump should not be committed to CVS before distcheck
> succeeds, and the package should not be uploaded without being
> tagged in the repository.
> 
> If files in the package were using RCS keywords, the above
> procedure would not be enough, because the commit would modify
> the files.  Hence an extra step is needed:
> 
>    1) distcheck
>    2) commit to CVS, and tag the release
>    3) dist
>    4) upload to gnu.org and sourceware.

If you're interested, I've been doing something like this for quite some
time with a project I maintain (http://sserver.sf.net for those
interested).  I have a target called release, which does the following:

1) cvs update
2) cvs commit
3) distcheck
4) update the ChangeLog with the release details
5) cvs commit
5) cvs tag with $PACKAGE-$MAJOR_$MINOR_$POINT
6) cvs checkout to ./$PACKAGE-$MAJOR_$MINOR_$POINT
7) update the configure.ac version (increments $POINT)
8) cvs commits the changes to the configure.ac

I then cd into ./$PACKAGE-$MAJOR_$MINOR_$POINT and run `make upload`
which does the following:

1) dist
2) uploads the dist files (the exact command and thus location to
upload to is specified via the configure.ac)

The reason I've separated the release and upload was I found that
sometimes the upload would fail (for whatever reason) and I didn't want
to create a new release just because of that. Also I'm too lazy to
lookup the rules and enter the manually when the upload fails.
Additionally it allows someone else to grab the tagged release from cvs
and do the uploading.

I've recently put this functionality into m4 macros that can be found in
the Autoconf Archive (http://autoconf-archive.cryp.to/ under automake
support), however they
are already outdated, but I'll try to make the new ones available ASAP
(actually you can grab the latest from
http://cvs.sourceforge.net/viewcvs.py/sserver/m4/, but the upload target
is broken :( and the instructions in ax_mk_macros.m4 are old; instead
you just add @INCLUDE_MK@ to the bottom of each Makefile.am).

Either way you may (or may not) find the concepts/techniques useful.

Cheers,

- --
Tom Howard

Public Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x433B299A
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD4DBQFCJmDjw1G4ZUM7KZoRAsDrAJwK7dphP10lOjYlzq/GpO40Ro0c4wCXe55P
8Hmdm484vsWQ3ghpUhQK8g==
=dqSw
-----END PGP SIGNATURE-----

Attachment: tomhoward.vcf
Description: Vcard


reply via email to

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