[ let's all smack OtherBill for breaking Ryan's and my replies :-) ] On Mon, Dec 11, 2000 at 01:45:48PM -0800, Mail Delivery Subsystem wrote: >...
I wrote: > > Does nobody read the STATUS file? Didn't I put all this in there and state > that it would get cleared up by tonite for our release tomorrow? > > ... ah well. > > On Mon, Dec 11, 2000 at 10:13:11AM -0600, William A. Rowe, Jr. wrote: > > Ok, > > > > two showstoppers exist for A9, in my (convoluted) mind; > > > > 1. is sdbm an -internally- packaged function, as is mm? (my 2c says yes) > > Nope. It will be exposed as apr_sdbm_*. > > Today, users can program directly to GDBM, DB3, whatever. By exposing it, we > will also allow people to program directly to SDBM. > > However, I would think that most people don't care about the specific DBM > backend and will just use apr_dbm_ functions. But when they *do* care, then > it makes sense for us to let them. > > > If so, it has no business being distributed in > > httpd-2.0/include/apr-util, > > It will be named apr_sdbm.h. > > > since we certainly wouldn't distribute mm.h either. Same goes with > > apu_config.h and apu_private.h. This means they don't belong in > > apr-util/include either. > > Yes, apu_private.h and apu_config.h will move to include/private/. > > > 2. aprs are driving me nuts. Either we use src/ folders around the sources, > > or we don't. Consistency is all I'm asking. > > +1 on src/ in the APRs. It scales to larger feature sets than when you omit > it. My APR directory has 21 subdirs, which I find excessive. APRUTIL could > easily grow to that size. > > > I'll fix either if we agree on how, but I would end up breaking the build. > > Perhaps someone on Unix/libtool could do so, and I'll clean up the win32 > > asap. > > No problem. I was already planning to do the decided-upon items. The use of > src/ within APR hasn't reached consensus in my mind, though. > > I would like to see more opinions on the src/ thing than myself, OtherBill, > and Ryan. We should not proceed on *any* course of action without that. I > suspect we will not have it resolved by tomorrow. I'm going to work on a > bunch of the items for the release, but we should do something to get a > write-up of the src-vs-not alternatives and get some more input. > > Cheers, > -g > > -- > Greg Stein, http://www.lyra.org/ -- Greg Stein, http://www.lyra.org/
