You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Karl Fogel <kf...@newton.ch.collab.net> on 2002/08/06 19:47:07 UTC
Where to define the version number?
Karl Fogel <kf...@newton.ch.collab.net> writes:
> > +dnl AC_CONFIG_SRCDIR *required*; sanity-checks that the our src dir exists.
> > +AC_INIT([subversion], [0.14.0], [http://subversion.tigris.org])
> > +AC_CONFIG_SRCDIR(subversion/include/svn_types.h)
Two recent patches have revealed that we may need to change where we
define the version of Subversion.
Currently, the "master" location is svn_version.h, where we define the
SVN_VER_MAJOR, SVN_VER_MINOR, and SVN_VER_MICRO constants.
Then Art Haas posted a patch that would have duplicated this
information in configure.in. Meanwhile, Scott Lamb posted a patch
which hints that we (I *think*) are essentially duplicating the
SVN_VER_MAJOR constant in build.conf... Only it's out of sync right
now, claiming 1 instead of 0 :-). Greg Stein may clarify this, but
for now I'll assume that the situation is as I've just described it.
So:
I'm wondering if svn_version.h is really the right place to define
these. If we did it in configure.in, then Art could use it, and it
would be easy to pass the same version information down to both
build.conf (which would become build.conf.in) and svn_version.h
(becomes svn.version.h.in).
Whatever we do, I think it's important that there be exactly *one*
place where its defined. If svn_version.h can be that place, and
everyone else just deduces it from there, that's fine. I'm just
guessing that it would be easier if it were configure.in.
Thoughts?,
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Where to define the version number?
Posted by Blair Zajac <bl...@orcaware.com>.
Karl Fogel wrote:
> I'm wondering if svn_version.h is really the right place to define
> these. If we did it in configure.in, then Art could use it, and it
> would be easy to pass the same version information down to both
> build.conf (which would become build.conf.in) and svn_version.h
> (becomes svn.version.h.in).
I'd like to have this in configure.in. We could actually do something
smart there, such as check if the tree is dev build with .svn directories
and find all the revision numbers for the files in the repos. This
would allow us to show more accurately which revision number was used
to build Subversion, something that I find lacking right now. Having
it say version 0.14.0 for many revisions is not ideal.
Configure.in could create something like this in a single revision tree:
Subversion Client, version 0.14.0 (dev build based on rev 2900)
and this in a mixed revision tree
Subversion Client, version 0.14.0 (dev build based on revs 2834, 2846, 2900)
For people submitting bug reports to us, this would help a lot. Even
though in the mixed revision case we don't know which files are at a
particular revision, this specific information won't be required unless
some debugging is taking place.
Best,
Blair
--
Blair Zajac <bl...@orcaware.com>
Web and OS performance plots - http://www.orcaware.com/orca/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Where to define the version number?
Posted by Scott Lamb <sl...@slamb.org>.
Karl Fogel wrote:
> Two recent patches have revealed that we may need to change where we
> define the version of Subversion.
>
> Currently, the "master" location is svn_version.h, where we define the
> SVN_VER_MAJOR, SVN_VER_MINOR, and SVN_VER_MICRO constants.
>
> Then Art Haas posted a patch that would have duplicated this
> information in configure.in. Meanwhile, Scott Lamb posted a patch
> which hints that we (I *think*) are essentially duplicating the
> SVN_VER_MAJOR constant in build.conf... Only it's out of sync right
> now, claiming 1 instead of 0 :-). Greg Stein may clarify this, but
> for now I'll assume that the situation is as I've just described it.
Arkadiusz Miskiewicz's "[PATCH] move all dlopen()ed modules to
subdirectory" fixes my problem - with it, the build.conf's version is no
longer needed from ra_loader.c, since it loads *.so in that directory.
(In concept - I think it was part one of a two-part patch.)
But yeah, if build.conf's version is supposed to be the same as
SVN_VER_MAJOR, something ain't right.
--
Scott Lamb
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Where to define the version number?
Posted by Branko Čibej <br...@xbc.nu>.
Greg Stein wrote:
>On Tue, Aug 06, 2002 at 02:47:07PM -0500, Karl Fogel wrote:
>
>>So:
>>
>>I'm wondering if svn_version.h is really the right place to define
>>these. If we did it in configure.in, then Art could use it, and it
>>would be easy to pass the same version information down to both
>>build.conf (which would become build.conf.in) and svn_version.h
>>(becomes svn.version.h.in).
>>
>>
>
>No can do. Windows does not use configure(.in), so you would end up defining
>the version number in configure.in *and* svn_private_config.hw.
>
>svn_version.h is the right place... that's why I put it there :-)
>
Thank you, Greg, for so gently giving them a piece of my mind. If *I*
had responded first, sparks would have flown. :-)
>>Whatever we do, I think it's important that there be exactly *one*
>>place where its defined. If svn_version.h can be that place, and
>>everyone else just deduces it from there, that's fine. I'm just
>>guessing that it would be easier if it were configure.in.
>>
>>
>
>Agreed on the "one place". I think we probably want to introduce
>SVN_VER_LIBRARY to contain the library version. We can then extract that for
>use in the Makefile for building libs.
>
>
I'm not sure I understand why the library version would be different
from SVN_VER_MAJOR. Changing the library version implies an incompatibla
ABI change, right? If that happens, eithre the the major or the minor
version number must be bumped.
Couldn't SVN_VER_LIBRARY just be $SVN_VER_MAJOR.$SVN_VER_MINOR?
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Move library version to svn_config.
Posted by Greg Stein <gs...@lyra.org>.
On Wed, Aug 07, 2002 at 07:41:07AM -0500, Scott Lamb wrote:
>...
> Yeah, that's what I'm referring to. gen-make.py hardcodes `basename
> $buildconf .conf`-outputs.mk and autogen.sh hardcodes build.conf. It
> just seemed funny that they were made mostly-configurable in
> gen-make.py, gen_base.py, and gen_make.py, when apparently no one uses
> it with anything other than build.conf. Not a huge deal.
When I first wrote it, I wanted to leave the gen-make.py tool /somewhat/
useful to other projects. Of course, when I got into the guts of it... it
really isn't all that project-portable (gen-make knows about the FS and
Apache and whatnot).
At this point, we could just say "screw it" and hardcode filenames into
gen-make.py. It is only a tiny stub over the build/ modules, so it isn't
like it is a bitch to simply replace it in the future.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Move library version to svn_config.
Posted by Scott Lamb <sl...@slamb.org>.
Greg Stein wrote:
> On Tue, Aug 06, 2002 at 06:26:11PM -0500, Scott Lamb wrote:
>>...
>>Question: why are the build.conf and build-outputs.mk filenames handled
>>the way they are? They're passed through several levels of Python code
>>but hardcoded in the end in gen-make.py or autogen.sh. I tried to match
>>it with the svn-version.h filename, but I confess I don't see the point.
>
> Hard-coded? gen-make.py only hardcodes the -outputs.mk suffix. Is that what
> you're referring to? As to why... well, why not? :-)
>
> autogen.sh has to hard-code something. It's the guy that gets the system set
> up. I don't see why it *shouldn't* hardcode build.conf.
>
> I gotta confess that I don't quite understand what you're driving at here.
>
> Cheers,
> -g
>
Yeah, that's what I'm referring to. gen-make.py hardcodes `basename
$buildconf .conf`-outputs.mk and autogen.sh hardcodes build.conf. It
just seemed funny that they were made mostly-configurable in
gen-make.py, gen_base.py, and gen_make.py, when apparently no one uses
it with anything other than build.conf. Not a huge deal.
--
Scott Lamb
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Move library version to svn_config.
Posted by Greg Stein <gs...@lyra.org>.
On Tue, Aug 06, 2002 at 06:26:11PM -0500, Scott Lamb wrote:
>...
> Question: why are the build.conf and build-outputs.mk filenames handled
> the way they are? They're passed through several levels of Python code
> but hardcoded in the end in gen-make.py or autogen.sh. I tried to match
> it with the svn-version.h filename, but I confess I don't see the point.
Hard-coded? gen-make.py only hardcodes the -outputs.mk suffix. Is that what
you're referring to? As to why... well, why not? :-)
autogen.sh has to hard-code something. It's the guy that gets the system set
up. I don't see why it *shouldn't* hardcode build.conf.
I gotta confess that I don't quite understand what you're driving at here.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
[PATCH] Move library version to svn_config.
Posted by Scott Lamb <sl...@slamb.org>.
Karl Fogel wrote:
> Yup. So we would make a separate SVN_VER_LIBRARY in svn_version.h,
> and parse it out for the build/install process, and also Scott's patch
> would use it?
[...]
> Scott, how would you feel about taking all of this on (i.e., extending
> your ra_loader patch to solve all of these problems)? Fine to say no,
> of course, just let us know so we can schedule it in that case.
Done. I haven't actually done a "make install" (no good machine handy)
but build-outputs.mk looks right and I can't imagine ra_loader.c being
wrong.
Question: why are the build.conf and build-outputs.mk filenames handled
the way they are? They're passed through several levels of Python code
but hardcoded in the end in gen-make.py or autogen.sh. I tried to match
it with the svn-version.h filename, but I confess I don't see the point.
--
Scott Lamb
Re: Where to define the version number?
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
Greg Stein <gs...@lyra.org> writes:
> The library version will *probably* match the major version since we use
> major version to indicate binary compatibility, which is what the lib
> version also does. I'm just not entirely positive, though, so it is probably
> best to keep the two numbers independent.
Ah, okay.
> It should be quite easy for us to extract the lib version from a header file
> (which would make it available to svn_ra.h for dynloading).
Yup. So we would make a separate SVN_VER_LIBRARY in svn_version.h,
and parse it out for the build/install process, and also Scott's patch
would use it?
> No can do. Windows does not use configure(.in), so you would end up defining
> the version number in configure.in *and* svn_private_config.hw.
>
> svn_version.h is the right place... that's why I put it there :-)
Zing! Twenty lashes with a wet noodle for my Unix-centric way of
thinking. Thanks for pointing this out.
> Agreed on the "one place". I think we probably want to introduce
> SVN_VER_LIBRARY to contain the library version. We can then extract that for
> use in the Makefile for building libs.
Maybe if I'd read your whole mail first, I wouldn't have redundantly
written this above.
Scott, how would you feel about taking all of this on (i.e., extending
your ra_loader patch to solve all of these problems)? Fine to say no,
of course, just let us know so we can schedule it in that case.
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Where to define the version number?
Posted by Greg Stein <gs...@lyra.org>.
On Tue, Aug 06, 2002 at 02:47:07PM -0500, Karl Fogel wrote:
>...
> Two recent patches have revealed that we may need to change where we
> define the version of Subversion.
>
> Currently, the "master" location is svn_version.h, where we define the
> SVN_VER_MAJOR, SVN_VER_MINOR, and SVN_VER_MICRO constants.
>
> Then Art Haas posted a patch that would have duplicated this
> information in configure.in. Meanwhile, Scott Lamb posted a patch
> which hints that we (I *think*) are essentially duplicating the
> SVN_VER_MAJOR constant in build.conf... Only it's out of sync right
> now, claiming 1 instead of 0 :-). Greg Stein may clarify this, but
> for now I'll assume that the situation is as I've just described it.
The library version will *probably* match the major version since we use
major version to indicate binary compatibility, which is what the lib
version also does. I'm just not entirely positive, though, so it is probably
best to keep the two numbers independent.
It should be quite easy for us to extract the lib version from a header file
(which would make it available to svn_ra.h for dynloading).
> So:
>
> I'm wondering if svn_version.h is really the right place to define
> these. If we did it in configure.in, then Art could use it, and it
> would be easy to pass the same version information down to both
> build.conf (which would become build.conf.in) and svn_version.h
> (becomes svn.version.h.in).
No can do. Windows does not use configure(.in), so you would end up defining
the version number in configure.in *and* svn_private_config.hw.
svn_version.h is the right place... that's why I put it there :-)
> Whatever we do, I think it's important that there be exactly *one*
> place where its defined. If svn_version.h can be that place, and
> everyone else just deduces it from there, that's fine. I'm just
> guessing that it would be easier if it were configure.in.
Agreed on the "one place". I think we probably want to introduce
SVN_VER_LIBRARY to contain the library version. We can then extract that for
use in the Makefile for building libs.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org