On Fri, Dec 08, 2000 at 04:20:17PM -0800, [EMAIL PROTECTED] 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. Cheers, -g -- Greg Stein, http://www.lyra.org/
