autoconf-patches
[Top][All Lists]
Advanced

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

Re: [PATCH] Don't infloop upon "make dist".


From: Jim Meyering
Subject: Re: [PATCH] Don't infloop upon "make dist".
Date: Sun, 02 Mar 2008 23:40:57 +0100

Eric Blake <address@hidden> wrote:

> According to Jim Meyering on 3/2/2008 2:39 PM:
> | You should never have to create .tarball-version manually.
> |
> |> 'make major' when using GNUMakefile (since 'make major' is run before the
> |> tag is created,
> |
> | Whoops.  That's backwards.  "make major" must be run *after* the
> | tag is created.  AFAIK, that's the only way I found that works.
> | I had to revamp the build/tag-related rules in coreutils'
> | Makefile.maint to reflect this.
>
> But that's what bothered me.  What if, in the process of 'make major', one
> of the checks fails, and I have to change code and recommit to fix the
> bug?  That means forcefully deleting and recreating the tag.  I suppose as
> long as I don't push anything in the meantime, the bogus tag will never
> leak into the public.  But I worry about the git admonition that once a
> tag has been published, you should not alter it - and it is easier to obey
> that dictum by not creating the tag until the build is correct.

True.  But if you follow the rules, it's pretty safe:

  0. Don't push *anything* until you've created and tested
     the final tarball.  Perhaps even delay until after you've
     uploaded the tarball(s) and downloaded/verified that their
     signatures are valid.

  1. run "make distcheck"
     if errors, then fix, commit and goto 1
  2. tag for release
     [[ at any point after this, upon failure delete the tag,
        fix the problem, commit and goto 1 ]]
  3. run "make alpha" (or beta or stable)
  4. perform any last-minute sanity tests using the just-created tarball
  5. upload the tarball
  6. download tarball+sig and verify
  7. write/post the announcement
  8. push your changes to the public repo

Yes, I've had to remove a tag and re-tag,
just before a release.  More than once.

> | As the name implies, that .tarball-version appears only in tarballs.
> | Never in your build directory, ever.
>
> So both files are created automatically, and both (should) get
> distributed?  .version gets created during the install-hook of 'make dist'
> for all make implementations, while .tarball-version gets created only by
> GNUMakefile during 'make major'?

The .tarball-version file is inserted into the tarball
via Makefile.am's dist-hook rule.  In that respect, it is
distributed, but it is never in the git repository.

In coreutils, .version is created via GNUmakefile and kept up
to date via rules in GNUmakefile and in Makefile.am.
It may be possible to remove some of those rules.

> Is there still a handy rule in GNUMakefile for tagging the tree

Not yet, but we do need one.  It's on my list, but I have done so few
releases it hasn't been a priority.  I'd put it in Makefile.maint,
since that's where most release-related things are.
It should ensure that $VERSION is of a very specific form,
that all files are checked in, etc.  Maybe also require
that the current git branch name is valid somehow.
It could even extract the version string from the NEWS file.

> (and does
> it require the presence of an environment variable to say what the new
> version should be)?

No.  Back before switching to git, I wrote a script to automate the
pre-and-post-release NEWS/configure.ac/ChangeLog version/date update dance.
Now that only one of those files remains (NEWS), automating pre/post updates
is less pressing.

> | In coreutils, I use .version for things like man pages that need to
> | depend on something to trigger a version-change-induced rebuild.
>
> So the idea is that .version should always be up-to-date, but impact only
> a minimal amount of the build process,

Right.

> while .tarball-version can be stale
> because it impacts autoconf and thus an entire rebuild?

No.  .tarball-version should never exist in a git-based
build tree.  It appears only when unpacking a tarball.

> I'd really like to see some of this documented better, particularly as I
> copy more of GNUMakefile into other projects like m4.

Indeed.  If I had taken the time to document it (or even to describe it
carefully), I would have understood it sooner.  Sorry about that.
Maybe this discussion can serve as a starting point.




reply via email to

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