Nathan Hartman wrote on Tue, 19 Nov 2019 18:25 +00:00:
> On Tue, Nov 19, 2019 at 12:04 PM Daniel Shahaf <d.s_at_daniel.shahaf.name> wrote:
> > The concept of having the binary know the `svnversion` info of the
> > working copy it was built from does make sense, however. We could make
> > gen-make.py add «-DFOO=`svnversion`» to CFLAGS. (There's already
> > something like that, «fakedefines», in the Windows-specific part of the
> > build generator.)
> That wouldn't do what we want either. If you build from a tarball,
> it'll bake "Unversioned directory" into the binaries. Also it would
> mean that you must have svn installed in order to build svn,
> regardless whether the sources were obtained from distribution tarball
> or otherwise.
> So... I guess what we're doing now makes sense.
> Oh well, it was a nice thought.
We could still do:
if any(map(re.compile(r'SVN_VER_TAG\s+" [(]under development[)]"').search, open('subversion/include/svn_version.h'))):
fakedefines.append("SVN_VER_TAG_OVERRIDE=" + subprocess.check_output(['svnversion', '-n']))
and in svn_version.h, surround the definition of SVN_VER with:
#define SVN_VER_TAG SVN_VER_TAG_OVERRIDE
#define SVN_VER_TAG " (under development)"
For this to work, we'll need to make the Unix part of the build generator
support fakedefines too. Tarball builds will get the revision number from
SVN_VER_TAG, which release.py munges at tagging time; branch_at_HEAD will get the
revision number if svnversion was available at build time, but not otherwise.
I suppose it's possible to do branch_at_HEAD builds without having svnversion
installed — for starters, by using https://github.com/apache/subversion/%c2%a0%e2%80%94
but anyone who does that can just send us a patch to define SVN_VER_TAG_OVERRIDE
Received on 2019-11-19 19:58:33 CET