[Top][All Lists]

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

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

From: Eric Blake
Subject: Re: [PATCH] Don't infloop upon "make dist".
Date: Sun, 02 Mar 2008 14:48:50 -0700
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20080213 Thunderbird/ Mnenhy/

Hash: SHA1

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.

| 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'?

Is there still a handy rule in GNUMakefile for tagging the tree (and does
it require the presence of an environment variable to say what the new
version should be)?

| 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, while .tarball-version can be stale
because it impacts autoconf and thus an entire rebuild?

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

- --
Don't work too hard, make some time for fun as well!

Eric Blake             address@hidden
Version: GnuPG v1.4.5 (Cygwin)
Comment: Public key at
Comment: Using GnuPG with Mozilla -


reply via email to

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