Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: neutral (nike.apache.org: local policy)
Message-ID: <49A2D176.7020705@apache.org>
Date: Mon, 23 Feb 2009 17:40:22 +0100
From: Mladen Turk <mturk@apache.org>
User-Agent: Thunderbird 2.0.0.17 (X11/20080915)
MIME-Version: 1.0
To: Paul Querna <chip@force-elite.com>
CC: dev@apr.apache.org
Subject: Re: svn commit: r745119 - /apr/apr/trunk/configure.in
References: <20090217152734.9E9FC2388B50@eris.apache.org>
 <20090217160341.GA14535@redhat.com> <499AE2B9.4020001@apache.org>
 <20090217162853.GA14547@redhat.com> <499BCE41.9090303@apache.org>
 <20090223110743.GA8447@redhat.com> <49A2CCDC.5040008@force-elite.com>
In-Reply-To: <49A2CCDC.5040008@force-elite.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

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)