apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject RE: Showstoppers: Alpha 9
Date Mon, 11 Dec 2000 21:50:43 GMT
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:gstein@lyra.org]
> Sent: Monday, December 11, 2000 3:45 PM
> To: new-httpd@apache.org
> Cc: apr@dev.apache.org
> 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/
> 

Mime
View raw message