Re: cvs commit: apache-2.0/src/lib/apr/test testargs.c ab_apr.c

[Greg Stein <gs...@lyra.org>]

On 20 Nov 1999 martin@hyperreal.org wrote:
> martin      99/11/20 14:05:28
> 
>   Modified:    src/lib/apr/misc/beos misc.h
>                src/lib/apr/misc/os2 misc.h
>                src/lib/apr/misc/unix misc.h
>                src/lib/apr/misc/win32 misc.h
>                src/lib/apr/test testargs.c ab_apr.c
>   Added:       src/lib/apr/include apr_getopt.h
>   Log:
>   Under Linux, I always got a
>   "libc.so.6: Warning: definition of 'optarg' overriding common
>    libapr(getopt.o): warning: common is here"
>   To make matters cleaner, I added an apr_getopt.h to go with the
>   various copies of getopt.c in the os subdirectories. In this header,
>   I renamed all getopt-API functions to "apr_<apiname>". This avoids
>   name clashes with system libraries.

Two questions:

* why wouldn't we use the library version of getopt() instead of our own?

* shouldn't that be ap_* ?


Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/

Re: cvs commit: apache-2.0/src/lib/apr/test testargs.c ab_apr.c

[Ryan Bloom <rb...@raleigh.ibm.com>]

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.	

Re: cvs commit: apache-2.0/src/lib/apr/test testargs.c ab_apr.c

[Martin Kraemer <Ma...@mch.sni.de>]

On Sat, Nov 20, 1999 at 02:49:16PM -0800, Greg Stein wrote:
> Two questions:
> 
> * why wouldn't we use the library version of getopt() instead of our own?

Good question. That's what I have been asking myself since the creation
of lib/apr/misc/unix/getopt.c -- after all, *nix had it first ;-)
But as APR seems to have chosen to deliver a version for unix as well,
we should at least try to avoid clashes with the regular versions.

> * shouldn't that be ap_* ?

Probably yes -- but then again the getopt source shouldn't be in
lib/apr/misc/unix/getopt.c but in ap/ -- and it's moved from there
to apr long ago.

I see you are having similar problems to me:

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

* 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 would have expected the lib/apr/configure stuff to find out that
my system *has* getopt (it was linux 2.x in this case) and set the
equivalent to "#define HAS_GETOPT 1" and *not* compile the lib/apr
version of it. And I would have expected it to supply a workable
alternative (which has a renamed interface, like apr_getopt(), and
perhaps provide compatibility glue like #define getopt apr_getopt).

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.

    Martin
-- 
<Ma...@MchP.Siemens.De>             |    Fujitsu Siemens
Fon: +49-89-636-46021, FAX: +49-89-636-41143 | 81730  Munich,  Germany