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.

Regards
-- 
^(TM)

Mime
View raw message