Re: Win32 build from 1.6.3 source tarball: svnversion.h missing and not generated?

[Pascal Quantin <pascal.quantin () gmail com>]

2011/11/17 Gerald Combs <gerald () 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-request () wireshark org?subject=unsubscribe