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 16:40:22 GMT
Paul Querna wrote:
> 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:
>> 1) A non-versioned library build has a different ABI to the standard 
>> build, because the library SONAME changes.
>> 2) Ballooning the number of possible APR ABIs is bad.
>> 3) It is trivially simple to work around the problem of having to copy 
>> symlinks without adding complexity to the APR build system.
>> We discuss changes on their technical merits.  Saying "it's perfectly 
>> legitimate" doesn't add much to that debate.  It would be "perfectly 
>> legitimate" to introduce a configure switch to make the library SONAME 
>> be "libfluffy-pink-clouds-1.so"; no laws would be broken that I'm 
>> aware of.
> +1, I agree with Joe on this.  This switch should not be present.

OK. I've remove it,
although still don't understand why something optional is
such a big deal, namely because it doesn't change anything
regarding default build.

>  If 
> you are bundling up a custom application, you can easily add some later 
> shell script to move around files however you want them to be called.

It's not that easy. It requires patching the configure.in,
but we'll have to live with that. The point is that moving isn't
enough. One needs to rewrite the apr-config and .lai file as well,
so making a patch to configure.in is much easier.


View raw message