On Tue, Jun 21, 2011 at 17:04, Peter Samuelson <peter_at_p12n.org> wrote:
>
> [Greg Stein]
>> > I know Debian bumped the so version when they switched from apr-0.9 to
>> > apr-1.x, i.e from libsvn_xxx-1.so.0 to libsvn_xxx-1.so.1. Perhaps we
>> > should do something similar and make apr-2 create libsvn_xxx-1.so.2?
>>
>> That works for ELF. How about Windows?
>
> Good question. libtool has machinery to track this stuff. My
> aforementioned patch uses libtool's "-version-info 0" and
> "-version-info 1". How does libtool handle -version-info on Windows?
We don't use libtool on Windows. Simple as that :-P ... IOW, we'd have
to figure out how to fix the problem within our current Windows
system.
>> Another approach to take for now, and work this out over time, is to
>> allow --with-apr2 to be specified *only* when --enable-maintainer-mode
>> is enabled. I doubt packagers will be turning that on :-)
>
> *Nod*. So, more or less table the issue until apr2 gets to a point
> where it's being shipped to end users and apr1 is not. I have no idea
> when that's expected to happen, but presumably it's not a concern for
> 1.7.x.
Right. We can futz with it over the 1.8 development lifecycle. But by
keeping it under the maintainer mode, we can also be sure that
somebody won't Do Something Wrong with it.
APR 1.x is going to be around for a long, long time. I don't know that
"apr1 is not" will ever happen because I think svn is going to
continue to rely on it, so it'll need to stick around.
Cheers,
-g
Received on 2011-06-21 23:14:11 CEST