Greg Hudson wrote:
>On Mon, 2004-05-10 at 02:53, Branko Èibej wrote:
>
>
>>I committed a prototype implementation of version query functions.
>>Please look at it, and if it's acceptable, I'll implement the rest of
>>the functions and add version queries to all the command-line tools.
>>
>>
>
>Uh, -1, unless I missed some design discussion on this.
>
The preliminary discussion happened mostly on IRC, I think, but I recall
some requests to users@ about getting the library version at runtime,
and also a comment in svn_version.h about that. Anyway, my commit was
intended to start this discussion. Since the commit is fairly small, I
thought it would be easier to start with working code and take it from
there. :-)
>Adding a new
>utility function here and there is fine, in my opinion, but adding a new
>subsystem should really not happen without prior discussion.
>
>
"Review after commit," and the old-boy network and stuff. :-)
>I am +0 on adding functions to query a library's version.
>
Cool.
>I am -0 on
>adding machinery to check library version mismatches at runtime, because
>I don't see a lot of potential for accidental mismatches and because I
>haven't seen much of that machinery in other projects.
>
>
* Lots of users have been burned by this, and got obscure error
messages instead of what they'de get with this scheme.
* We check the BDB version at runtime.
* We check RA and FS(A)P versions at runtime.
>Specific comments on the implementation:
>
>+#define SVN_VER_GEN_PROTO(name) \
>+#define SVN_VER_GEN_IMPL(name) \
>+#define SVN_VER_COMPATIBLE(name) \
>+#define SVN_VER_CALLBACK_COMPATIBLE(name) \
>
>I do not believe we should be using the preprocessor to this extent.
>The preprocessor is not our friend. Suppose I run into a problem
>involving svn_subr_version and I want to find out where it's defined? I
>can't grep for it, because it was defined with SVN_VER_GEN_IMPL(subr).
>
>
I agree this could be a problem, even though GCC at least will point to
the macro definition, and GDB will single-step through it. On the other
hand, the svn_*_version functions are so simple that I'm prepared to
formally prove their correctness, and I decided on the macro approach
because we're going to have many of them, and definitely want them all
to be the same.
I'd be prepared to reconsider if problems show up in SWIG and/or Doxygen.
>+svn_boolean_t svn_ver_compatible (const svn_version_t *versioninfo,
>+svn_boolean_t svn_ver_callback_compatible (const svn_version_t *versioninfo,
>
>The asymmetry between the two version arguments (one specified as a
>structure pointer, the other split out into four parameters) seems
>weird.
>
>
Yes, it does. It's there because I didn't see any other way to generate
the shorthand macros. I do see a better way now, and will change those
prototypes.
>What's the definition of "callback compatibility?" The implementation
>seems to simply reverse the direction of the compatibility test. To the
>best of my knowledge, we treat changing the signature of a callback as
>if it were changing the signature of any API which uses that callback,
>so we have no concept of "callback compatibility."
>
>
This is one of the things I wanted to discuss, as it hinges on the
interpretation of our versioning rules. We have a number of callback
functions that the user of a library has to register in many batons. If
our versioning guarantees cover such callbacks in the same "direction"
as ordinary calls, then the callback-compatibility check can go away --
I'd like to see that happen, too. But I need a second opinion regarding
the interpretation of the versioning guarantees.
>Compatibility is directional, but the docstring for svn_ver_compatible
>does not say which direction it checks compatibility in.
>
>
Hm? Yes it does; "for calls into the library", and callback
compatibility is "for callbacks from the library", that is, in the other
direction.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon May 10 21:01:11 2004