apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <gst...@lyra.org>
Subject Re: Showstoppers: Alpha 9
Date Mon, 11 Dec 2000 21:51:35 GMT
[ 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/

View raw message