On 12/16/04 15:56:54, Philip Martin wrote:
> John Lenz <lenz@cs.wisc.edu> writes:
>
> > I keep trying to repeat this, but no one seems to get it. So you will
> have
> > to pardon my shouting.
> > THERE IS NO MORE ABI ANYMORE
> > let me repeat that
> > THERE IS NO MORE ABI ANYMORE
>
> I remember your previous email about the removal of the run-time
> library. It sounded like an improvement[1].
>
> That doesn't alter the fact that we write C code to support SWIG, in
> swigutil_py.c. That API/ABI has changed in the past, and that API/ABI
> is still there. Your patch makes further changes to that C code, and
> as I understand it SWIG is in development and provides no guarantees
> that 1.3.25 will be API/ABI compatible 1.3.24. Has the SWIG project
> changed it's position?
Not a hard guarantee until 2.0, but from this point on we will make more
effort to preserve it. I have introduced a SWIG_RUNTIME_VERSION define,
which is currently set at "1", and I will bump that whenever the runtime
ABI or API changes. The RUNTIME_VERSION is separate from SWIG version
because the runtime might be stable over SWIG releases.
I can guarantee that any API or ABI change will come along with a change in
the SWIG_RUNTIME_VERSION define.
Seeing as subversion only uses SWIG_TypeQuery, SWIG_ConvertPtr, and
SWIG_NewPointerObj (SWIG_MakePtr) those will not be changing in their API.
>
> [1] Although as I recall there was something about communication via a
> global python variable. If I mix 1.3.X and 1.3.Y will it always work
> or is it possible that I will I get a runtime python error?
The data is stored in a global variable that takes into account the
SWIG_RUNTIME_VERSION. So if you have one module built with 1.3.24 and one
module built with 1.3.25, if they have the same SWIG_RUNTIME_VERSION then
the two modules will share type information. Thus since the
RUNTIME_VERSION will change whenever the ABI changes, modules built with
the same RUNTIME_VERSION will work together.
If say in 1.3.25 we bump RUNTIME_VERSION because of some changes to some
part of the runtime stuff, then the two modules would not even see each
other because they would look for different global variables. They will
not work together (that is, share type info), but no crashes or weird
errors. You would get type errors trying to pass a pointer created in one
module to the other, but that is unavoidable... Well, it would be possible
to support all previous RUNTIME_VERSIONs when we bump it, but I don't plan
on doing it often and the extra work there is of very little use.
Note as well you could have three modules built with 1.3.24 and two modules
built with a new changed RUNTIME_VERSION, and they would happily live side
by side, the new modules sharing with each other and the 1.3.24 sharing
with each other. Thus say subversion builds with RUNTIME_VERSION=2 and
some other random project builds with an older SWIG. subversion won't care
and won't be affected, something that was impossible with the old library
approach.
Note that since we removed the library libswigpy, it is A LOT easier to do
this type of versioning. Versioning with libraries is messy and brittle.
John
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Dec 16 23:24:44 2004