Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Date: Tue, 28 Nov 2000 18:06:38 -0800
From: Greg Stein <gstein@lyra.org>
To: Branko Cibej <brane@xbc.nu>
Cc: dev@apr.apache.org
Subject: Re: new APR package
Message-ID: <20001128180638.I25840@lyra.org>
Mail-Followup-To: Branko Cibej <brane@xbc.nu>, dev@apr.apache.org
References: <20001128173157.F25840@lyra.org> <3A2462F0.9070304@xbc.nu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2i
In-Reply-To: <3A2462F0.9070304@xbc.nu>;
 from brane@xbc.nu on Wed, Nov 29, 2000 at 02:59:12AM +0100

On Wed, Nov 29, 2000 at 02:59:12AM +0100, Branko Cibej wrote:
> Greg Stein wrote:
> 
> > I think that's all that I've got. Thoughts? Comments?
> 
> Maybe tweak APR scrpits so that they automagically find, configure and 
> build APRUTIL if somebody happens to unpack it (or checkout) in the APR 
> top-level directory? Then those users of APR that need APRUTIL too will 
> only have to deal with a single package (but would still link two 
> libraries, of course).

The dependency goes the other way: APRUTIL depends upon APR. APR will know
nothing about APRUTIL.

Now... your statement could be applied to APRUTIL: if APRUTIL finds APR
unpacked inside it, then it would do the right magic.
[ much like SVN does sub-config on APR and Neon which are unpacked inside of
  its directory (altho the SVN case requires the subpackages) ]

It also seems feasible to create a "super package" of APR and APRUTIL. I
would even presume that if somebody builds an APR RPM, they would include
both libraries in it.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/