Guy Harris wrote:
On Nov 2, 2011, at 11:19 AM, Guy Harris wrote:
On Nov 2, 2011, at 10:26 AM, Guy Harris wrote:
On Nov 2, 2011, at 10:16 AM, Jeff Morriss wrote:
Oh, shoot. Looks like svnversion.h is removed by clean and/or dist-clean.
So it should be generated only if you're building from SVN, and should be included in source tarballs, and should be removed only by maintainer-clean.
I've checked in a change to do that, and will schedule it for the next 1.4.x and 1.6.x release, unless somebody can come up with a good reason to remove svnversion.h with clean or dist-clean. Speak up soon....
Well, the build is failing because "make distclean" isn't getting rid of it.
To quote the automake manual:
* Distributed files should never depend upon non-distributed built files.
* Distributed files should be distributed with all their dependencies.
* If a file is intended to be rebuilt by users, then there is no point in distributing it.
svnversion.h is made by make-version.pl, and to get the SVN version you presumably have to be in an SVN tree, so svnversion.h's "dependency" is on, in a sense, .svn and its contents, so, from what the automake manual says, if we ship svnversion.h, we have to ship the .svn tree as well.
I don't think we want to do that.
So, either
1) we need to arrange to define HAVE_SVNVERSION_H if building from SVN, *not* define it if building from a release tarball, protect the includes of svnversion.h with #ifdef HAVE_SVNVERSION_H/#endif;
2) we need to have make-version.pl work when run from a source tarball, for some reasonable definition of "work";
and, in either case, not distribute svnversion.h with the tarball and remove svnversion.h with "make distclean".
So here are (I think) the scenarios we're trying to cover:
a) Builds from SVN (typically on trunk/ but also the release trunks):
the exact SVN version is useful to know and the file can easily be made.
Easy.
b) Release source tarballs: the exact SVN version is not very important
(the version is the version is the version) and the file can't be
generated (by the user). And automake won't let us deliver it because
the file is generated.
c) Daily build source tarballs: the exact SVN version *is* interesting
(it's nice to know that, for example, the thousands of SVN versions
between when 1.6.0 was released and when 1.7.0 will be released are not
all, in fact, 1.7.0--remember the sunfreeware.com incident[1]?) but we
have the same problems as (b).
[1] https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=1413#c8
Unfortunately both options above mean we lose the SVN version in cases
(b) and (c).
Should svnversion.h instead be checked in to source control and
automatically updated at each checkin (by a trigger)?
Or should 1.7.[even number] mean "an SVN build between versions" and
1.7.[odd number] mean "a development release", thus partially removing
the interest in having an SVN number in (c)?
Or...?