apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <gst...@lyra.org>
Subject apu_private and optional stuff (was: Re: cvs commit: apr-util/src/dbm apr_dbm.c)
Date Sat, 09 Dec 2000 01:54:22 GMT
On Fri, Dec 08, 2000 at 04:20:17PM -0800, rbb@covalent.net wrote:
> > > 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?
> > > apr-util/include/private?  We don't need arch/ anything, since headers shouldn't
> > > change the same way in apr-util (it's already cross-platform, right :-?)
> > 
> > We could move apu_private to a subdirectory, but why? A handy subdir was
> > available in APR, so that was an easy choice to hide the include file. I say
> > that we leave the file and simply tell people "you're an adult. listen to us
> > when we say don't include it."
> That didn't work with apr_private.h, which should it work for
> apu_private.h?

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.

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


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

View raw message