On 11/3/11 2:52 PM, Jeff Morriss wrote:
> 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...?
I updated make-version.pl to clarify the different things that it does.
It can now store the SVN revision in config.nmake, which can then be
used to rebuild svnversion.h. Updating config.nmake was a lot easier
than a post-commit hook since we were storing other version information
there.
