Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: pass (asf.osuosl.org: local policy)
Message-ID: <445F8A78.2030208@rowe-clan.net>
Date: Mon, 08 May 2006 13:14:16 -0500
From: "William A. Rowe, Jr." <wrowe@rowe-clan.net>
User-Agent: Mozilla Thunderbird 1.0.7-1.1.fc4 (X11/20050929)
MIME-Version: 1.0
To: Mladen Turk <mturk@apache.org>
CC: APR Developer List <dev@apr.apache.org>
Subject: Re: Moving apr_xlate from apr-util to apr-iconv
References: <445F7C11.3050601@apache.org> <445F824B.9060500@rowe-clan.net>
In-Reply-To: <445F824B.9060500@rowe-clan.net>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Mladen, perhaps I failed to make my point below.  *Today* you can build your
very own apr for your app with whatever features enabled/crippled that you like.

The point I was illustrating below was a (future) way to build apr component
by component, such that, for example, the apr_ldap lib and dependent libldap,
liblber, libssl and libcrypto would only be loaded in process if your app
actually chooses to link to libaprutil-2-ldap.so.

But you can build your apr today without iconv if that's what you are trying
to accomplish.

William A. Rowe, Jr. wrote:
> At the moment it hauls in a number of libraries, which makes moving binaries
> around a rather worthless exercise in futility.  The right answer is to break
> apart apr-util into seperately loadable libraries in APR-util v2.0 - so that
> all those dependencies are split, and it begins to look alot more like the
> way that python, perl, and jar support of these various features break apart
> all the subdependencies.  apr_xml becomes one lib, apr_xlate becomes another,
> apr_ldap becomes a third, etc.