apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mladen Turk <mt...@apache.org>
Subject Re: svn commit: r745119 - /apr/apr/trunk/configure.in
Date Mon, 23 Feb 2009 12:52:43 GMT
Joe Orton wrote:
> On Wed, Feb 18, 2009 at 10:00:49AM +0100, Mladen Turk wrote:
>> Joe Orton wrote:
>>> So you really need a hack to the configure script which introduces a 
>>> new way to break ABI compatibility with the standard build, just so you 
>>> can avoid copying some symlinks in an obtuse distribution mechanism?  I 
>>> don't see it.
>> First of all it's not a hack.
>> It's a perfectly legitimate way how you can build a shared library.
>> Any other discussion would only lead to philosophical and
>> political rather then technical reasons.
>> It's off by default, and if you don't need it, don't use it.
> If you don't have any technical justification for this other than "it 
> lets me avoid copying a symlink" then I'm -1 on this change:

I didn't think it is that important (well I thought it was
self understood). Anyhow ...

If you think of APR as a system library used by multiple
applications, then this usage is bogus of course.
I doubt anyone would even consider doing that.

However if you create a self-contained application that uses
APR, and distribute that application detached from the
system then it's up to you to maintain the versioning.
Weather that's a smart decision its up to app producer
to decide.

As an example take a look at httpd build by --with-included-apr
APR in this case is detached from whatever apr exists in the
universe. IMO it's pointless to keep apr so symlinks, just like
we don't maintain them for modules.

However that wasn't the reason for this.

I'm working on a project (will be part of jakarta)
that uses virtual file system (you might guess it doesn't
support the symlinks) for distributing the java and
native code together in a single archive. Symlinks are not
supported and referencing the .so directly by
version number introduces complexity both during build and
runtime loading.

So, IMHO at the end this doesn't differentiate from the
--disable-threads on a system that has threading support.
If someone chooses to build apr without threads it must
be aware it broke the ABI.


View raw message