> > 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? > > 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. 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". Ryan _______________________________________________________________________________ Ryan Bloom [EMAIL PROTECTED] 406 29th St. San Francisco, CA 94131 -------------------------------------------------------------------------------
