Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: neutral (athena.apache.org: local policy)
Message-ID: <474B2B71.1000201@rowe-clan.net>
Date: Mon, 26 Nov 2007 14:24:17 -0600
From: "William A. Rowe, Jr." <wrowe@rowe-clan.net>
User-Agent: Thunderbird 2.0.0.9 (X11/20071115)
MIME-Version: 1.0
To: dev@apr.apache.org
Subject: Re: APR 2.0 proposals
References: <20071123103706.GA4169@redhat.com>
 <20071126195558.GA82120@zeus.kimaker.com>
In-Reply-To: <20071126195558.GA82120@zeus.kimaker.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Ryan Phillips wrote:
> 
> I agree APR and APR-util should be combined into one, but I hate the notion
> of chunking the library into multiple parts.  If a developer wants to
> disable a feature, then a simple --without-xml or --without-dbm should
> suffice. 

Not really - we need to all play against APR installed in a common location.
This makes the whole "I only need xml and ldap" usage model a real PITA.

> What is the benefit in chunking a library?  In the case with embedded
> projects (which I work on), I am more inclined to simply disable the bits I
> am not using on the configure line and be done.  I don't care that they are
> split into libapr-xml and friends.

Agreed, I don't mind a new model of apr-1-config --using-xml --using-ldap
to get compile options.

But I'm not sure a whole slew of libaprfeature-2.so linkages is the answer,
especially for a complex use case like httpd.

Bill