apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Branko ─îibej <br...@xbc.nu>
Subject Re: new APR package
Date Wed, 29 Nov 2000 02:25:37 GMT
Greg Stein wrote:

> 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) ]

Whatever. When I wrote that I was thinking of GCC, whose top-level 
makefile will configure any marginally well-behaved package that happens 
to be dropped in. But I realise now that our case is a bit different.

> 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.

That was the idea, yes.

-- 
Brane ─îibej
    home:   <brane@xbc.nu>             http://www.xbc.nu/brane/
    work:   <branko.cibej@hermes.si>   http://www.hermes-softlab.com/
     ACM:   <brane@acm.org>            http://www.acm.org/



Mime
View raw message