httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <>
Subject RE: cvs commit: httpd-2.0/support ab.c ab.dsp htdigest.c htdigest.dsp htpasswd.c htpasswd.dsp logresolve.c logresolve.dsp rotatelogs.c rotatelogs.dsp
Date Thu, 28 Dec 2000 17:52:39 GMT
> From: []On Behalf Of
> Jeff Trawick
> Sent: Friday, December 22, 2000 11:24 AM
> "William A. Rowe, Jr." <> writes:
> > > So what if we have some autoconfiguration requirements in one of the
> > > support programs... It automatically goes in APR (-0)?  The support
> > > programs get their own configure script (-1)?
> > >
> > > Is APR now promising to figure out existence of all header files that
> > > any APR app might use and export as APR_HAVE_xyz_H?  What about
> > > functions?
> > 
> > I was thinking about that q as I did this patch.
> > 
> > If you want to avoid creating a config script for every consumer of this
> > library then, yes, I'd suggest any "Platform Dependent" situation would
> > be covered here.  This is why we create these for Apache, and any APR
> > consumer is duplicating that effort if we don't roll it into APR.
> I don't think we can avoid a non-trivial consumer of APR from having
> its own config script.  What will happen (IMHO) is that we will
> happily add trivial stuff like testing for headers or functions or
> what-not but not feel comfortable adding other stuff like
> does-function-xyz-work unless it is meaningful for APR (or apps which
> core APR developers work on).

Ok, clarifying, for -trivial- apps (say, the Apache support/ code, for
example) we shouldn't have to add config script tests to come up with a
very simple app.  OTOH, a non-trivial app (apache, subversion, etc) will
always have their own tests, but should be able to leverage what APR
already does for them.  Ergo, not only can't we indiscriminately -not-
pull out tests, we cannot change the way we arrive at 'our' answers, e.g.
APR_HAVE_MMAP_H, since if they care, they will look at our method of
deriving the test and decide if it's legit for their app.
> Another way of putting this is that we will be willing to do the stuff
> which is trivial for the app to do itself but we won't be willing to
> do much hard stuff.  (Who here likes to commit patches they don't
> understand or have no way to verify?)

Ryan will handle this :-)>

View raw message