Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: pass (nike.apache.org: domain of chip@force-elite.com designates
 72.232.80.58 as permitted sender)
Message-ID: <49A2CCDC.5040008@force-elite.com>
Date: Mon, 23 Feb 2009 08:20:44 -0800
From: Paul Querna <chip@force-elite.com>
User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209)
MIME-Version: 1.0
To: 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>
In-Reply-To: <20090223110743.GA8447@redhat.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

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.  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.

-Paul