Return-Path: Delivered-To: apmail-apr-dev-archive@apr.apache.org Received: (qmail 76296 invoked by uid 500); 13 Sep 2002 17:47:35 -0000 Mailing-List: contact dev-help@apr.apache.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Delivered-To: mailing list dev@apr.apache.org Received: (qmail 76275 invoked from network); 13 Sep 2002 17:47:35 -0000 X-pair-Authenticated: 66.9.75.43 Message-ID: <3D8224BA.2010605@electricjellyfish.net> Date: Fri, 13 Sep 2002 13:47:38 -0400 From: Garrett Rooney User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: David Reid CC: APR Development List Subject: Re: [PROPOSAL] Create apr-build repository References: <20020913173631.GT1555@apache.org> <00f501c25b4d$307c0a00$7300a8c0@MITHRIL> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N David Reid wrote: > Not sure I like this. Shouldn't the other project just use the apr files > rather than copying their own versions? > > More context please... if the projects use the apr files, then you end up with the situation that apr-util is in now, where one cannot actually build apr-util separately from apr. even if apr is installed on the system already, you actually have to have the apr directory tree sitting next to the apr-util directory tree or you can't even run configure. since apr-util is supposed to be a separate project, this seems like a pretty bad situation to me. it would be one thing if apr installed the files on the system, where the build process of the other projects could find and use it, but requiring you to actually have the source tree there seems a bit much. -garrett