httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ryan Bloom <...@raleigh.ibm.com>
Subject Re: cvs commit: apache-2.0/src/lib/apr/test testargs.c ab_apr.c
Date Mon, 22 Nov 1999 12:12:35 GMT

The reason APR has provided it's own version of getopt, is that different
*nix's provide different getopt's.  At the time, we were using options
that Linux's version of getopt didn't support at all.  I'm not sure if we
are still using those options.  Regardless, the decision was made to
provide a version of getopt in APR so that ap_getopt looked the same on
all systems.

As for your errors, I can't explain them.  I am under the impression we
have been using ap_getopt for months, and I have yet to have problems when
compiling.  I will look into it however.

> * what should be apr stuff, what should be ap stuff?

APR is a Portable Run-time.  If there is a function that we use across all
platforms _and_ it isn't HTTP specific, chances are it will end up being
moved to APR.  I expect most of the ap directory to  either be moved down,
or tp http_main over time.

> 
> * what is the reasoning behind putting something into apr, and how is
>   it deactivated/circumvented/renamed/whatever if the system supports
>   the functionality in a reasonably reliable way?

I gave the reasoning above.  How to circumvent, we check for it using
autoconf.  As I mentioned, getopt is the exception.  Getopt is not
standardized across *nix's, so we are providing a version of getopt that
is standard for all of our platforms.  This way, we know it works the
same, and we can use any of the four variables provided by ap_getopt.  I
believe the problem was that optreset wasn't defined by Linux 2.0.X or
2.2.X, but I could be wrong.  This was all detailed and decided on
new-httpd a couple of months ago.

> I think that design decisions like these should be written down
> somewhere so that we get a homogenous design rather than a pile of
> hacks. I am aware that my solution was a hack, btw. But lacking a
> clean design, I saw no good alternative.

ALL APR design decisions have been documented.  Those which are applicable
to new programmers coming in, are documented in APRDesign, which can be
found in the src/lib/apr directory.  It has bas there for some time, and
it details those things anybody modifying APR should know.  I have been
asking people to read it before writing parts of APR, because if the
guidelines aren't followed, we have to change the code.  For example, when
I started, I didn't use the argument order that APR now uses.  Because of
that, I had to re-write ALL of the APR function prototypes.  That was a
royal pain.

More complex design decisions tend to either go through new-httpd, or on
rare occasion, through private e-mail between me and the developer working
on it.  Private mail has so far been a way for me to discuss ideas before
bringing them to new-httpd.

I hope that answers your questions.

Ryan

_______________________________________________________________________
Ryan Bloom		rbb@raleigh.ibm.com
4205 S Miami Blvd	
RTP, NC 27709		It's a beautiful sight to see good dancers 
			doing simple steps.  It's a painful sight to
			see beginners doing complicated patterns.	


Mime
View raw message