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. ___________________________________________________________________________ Sent via: Wireshark-dev mailing list <[email protected]> Archives: http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:[email protected]?subject=unsubscribe
