2011/11/17 Gerald Combs <ger...@wireshark.org>
> 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.
>
Hi Gerald,
since your commit I'm facing a small issue when compiling trunk for
Windows. The following command (in top Makefile.nmake):
cd plugins
$(MAKE) /$(MAKEFLAGS) -f Makefile.nmake install-plugins
tries to install the plugins in a folder named plugins\1.7.1-SVN-#### while
Wireshark expects them to have them in a folder named plugins\1.7.1 (they
fail to load unless i copy them to the plugins\1.7.1 folder).
It appears due to the change done in config.nmake so as to set
VERSION_BUILD to $(SVN_REVISION).
Not sure what is preferable. I guess it would be better to avoid generating
a new plugin folder each time the revision number increases.
Regards,
Pascal.
___________________________________________________________________________
Sent via: Wireshark-dev mailing list <wireshark-dev@wireshark.org>
Archives: http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
