Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Errors-To: <wrowe@rowe-clan.net>
Message-Id: <6.1.0.6.2.20040702142002.05302ec0@pop3.rowe-clan.net>
Date: Fri, 02 Jul 2004 14:21:33 -0500
To: Branko =?iso-8859-1?Q?=C4=8Cibej?= <brane@xbc.nu>
From: "William A. Rowe, Jr." <wrowe@rowe-clan.net>
Subject: Re: apr-iconv 1.0
Cc: dev@apr.apache.org
In-Reply-To: <40E59F80.8020000@xbc.nu>
References: <6.1.0.6.2.20040623142928.07b85ec0@pop3.rowe-clan.net>
 <40E4A125.2000206@xbc.nu>
 <6.1.0.6.2.20040702022101.0413ee38@pop3.rowe-clan.net>
 <40E59F80.8020000@xbc.nu>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

At 12:46 PM 7/2/2004, Branko =C4=8Cibej wrote:
>William A. Rowe, Jr. wrote:
>
>>At 06:41 PM 7/1/2004, Branko =C3=84=8Cibej wrote:
>>
>>>Thoughts? I think 1.0 is an auspicious time to make this change,=
 especially if we declare apr-iconv to be an implementation detail of=
 apr_xlate.
>>
>>The nifty bit is, if we declare apr-iconv to be an internal,=
 implementation
>>detail of apr_xlate - we are free to adopt your suggestions in 1.0.1 :)
>That's true.
>
>Then I suggest we really do close off apr-iconv. This means the apr-iconv=
 headers shouldn't get installed, right? Among other things.

++1 to that idea, as long as apr-util internally gets the -I / -L paths to=
 the
build of apr-iconv, and they don't persist in the apu-1-config file.

Bill