Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Errors-To: <wrowe@rowe-clan.net>
From: "William A. Rowe, Jr." <wrowe@rowe-clan.net>
To: <dev@apr.apache.org>
Subject: RE: apu_private and optional stuff (was: Re: cvs commit:
 apr-util/src/dbm apr_dbm.c)
Date: Sat, 9 Dec 2000 00:50:31 -0600
Message-ID: <002601c061ac$52d89a10$92c0b0d0@roweclan.net>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
In-Reply-To: <20001208175422.O30644@lyra.org>
Importance: Normal

> From: Greg Stein [mailto:gstein@lyra.org]
> Sent: Friday, December 08, 2000 7:54 PM
> 
> > > > One last observation, sdbm.h does _not_ belong in apr-util/include/ and neither
> > > > does the apu_private stuff.  Suggest we move those on out of there, but where?
> 
> There are three locations that I can think of to move this header:
> 
> 1) include/private/apu_private.h
> 2) src/apu_private.h
> 3) src/include/apu_private.h
> 
> I'm +0, +0, and -0 respectively, and +1 on leaving it.

I simply veto leaving it.  Given your two preferences, I'd be +1 on 1),
I like include/private/foo better than putting any .h in the root of src/,
and we are debating if src/ is appropriate.  [I still absolutely oppose
two seperate structures for the two sister trees!!!  You have both made
valid points, and I'm leaning twords the fact that users aught to be 
allow to 'pick and choose' which pieces of which libraries they want,
which kind of implies loosing src/.  But my only LOUD comment is to keep
them the same and make it easy on our brain cells :-]

> > > > Note we don't appear to have an apr-util.h just yet for compiled-in features
> > > > of the lib... we need one, no?
> > > 
> > > if/when we have separable features.
> > 
> > We absolutely MUST have separable features, and we must be able to build
> > just those features that are required.  This code has no one thing that
> > ties it all together, so there is no reason to think that any project
> > other than Apache will want it all.  Inflicting it on everybody is not a
> > valid way to do this.
> 
> We should be able to do this with some configure magic. A number of
> AC_ARG_ENABLE() macros; default to enabled.
> 
> > I would still like to see a statement for what
> > belongs in this library, because right now the definition of this library
> > is "kitchen sink of portable routines".
> 
> I think that you phrased it yourself, with respect to the APR core: a
> library to help create portable applications. Some of the other wording that
> you've used is basically "utility functions to assist with easily creating
> [portable] applications." Something along those lines.
> 
> The APR/APRUTIL combo is a way to build portable applications. APR is the
> core of portable, and APRUTIL provides further assistance.

So if we can agree that apr-util is a collection of many 'library' like features,
none of which warrent a full blown library on their own, then I'm +1 to loose
the src/ layer of apr-util, and let them pick and choose what 'librariettes'
they need for their app.  And each of these little bits can have it's own purpose.