httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Kraemer <Martin.Krae...@mch.sni.de>
Subject Re: cvs commit: apache-2.0/src/lib/apr/test testargs.c ab_apr.c
Date Mon, 22 Nov 1999 09:45:45 GMT
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
-- 
<Martin.Kraemer@MchP.Siemens.De>             |    Fujitsu Siemens
Fon: +49-89-636-46021, FAX: +49-89-636-41143 | 81730  Munich,  Germany

Mime
View raw message