On 4/10/06, Greg Hudson <ghudson@mit.edu> wrote:
> On Mon, 2006-04-10 at 15:42 -0700, Justin Erenkrantz wrote:
> > I don't view APR's ABI as part of Subversion's.
>
> That's an odd statement. Subversion's ABI demonstrably changes if you
> compile it against APR 0.9 and then again against APR 1.0 (both in their
> default configurations), as the size of apr_off_t changes, and that type
> is used in several Subversion structures and functions.
So? I view it the same as if a libc ABI changes: Subversion can't
hide all of its dependencies - we're a compiled binary targeted at a
specific platform with specific libraries, not a dynamic interpreted
program.
Please take a look at how a typical glib, gtk+, etc. apps expose
glib/gtk+ ABIs. When a glib primative size changes (which has the
potential of changing in a couple of 2.x.y point releases of glib), so
does the ABI for that downstream application.
The solution that downstream packagers seem to use is to ensure that
all of the versions are upgraded in-line - which works fine for SVN
and APR too.
But, the solution to this is not to create our own internal copy of
every APR data structure and only expose our 'private' copy - because
if the APR ABI does indeed change without Subversion recompiling,
we're just as horked as we were before. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Apr 11 01:11:32 2006