I'm +1 on everything below ... including adding src/ to apr since neither Ryan or I feel real strongly about it. Either way, with or without src/, we should be able to pick-n-choose our packaging, and either way we will stumble somewhere. Let's move forward, and thanks for the offer to clean up those issues, I'll be sure win32 builds again :-)
> -----Original Message----- > From: Greg Stein [mailto:[EMAIL PROTECTED] > Sent: Monday, December 11, 2000 3:45 PM > To: [email protected] > Cc: [EMAIL PROTECTED] > Subject: Re: Showstoppers: Alpha 9 > > > 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/ >
