Not exactly. I did some work a while ago to try to do this, but my
solutions were rejected, so they were removed. So, there is nothing in
there now, but there has been work done. Feel free to do more. :-)
Ryan
On Mon, 8 Jan 2001, Sascha Schumann wrote:
> Hi,
>
> am I right in assum
Hi,
am I right in assuming that there were no efforts so far to
make apr-util work with an APR which was not build in its
source directory (i.e. an httpd 2.0 build in a separate dir)?
- Sascha
Folks,
This is a small patch that's very much a starting point. Basically
following Deans suggestion we should be tracking what options we have set on
a socket and using the cached information to avoid system calls. I've used
an int and the system defined values as that way we can use the mask f
Hiya,
This is part 1 of a multi-part patch to include APR_DECLARE(foo_t)
statements for all external APR functions. To aid verification (and reduce the
risk of a massive screw-up) I'm
sending a seperate patch for each
functional group starting with apr_pools. I'll wait for approval on this on
Jim Jagielski <[EMAIL PROTECTED]> writes:
> Hmmm... right now, if CFLAGS (et.al.) set, the hints.m4 stuff is
> *not* used (they are only set if these env vars are null)...
> I'm thinking now that that's not the right thing. These
> should be set (added) no matter what.
very minor point: there is
Hmmm... right now, if CFLAGS (et.al.) set, the hints.m4 stuff is
*not* used (they are only set if these env vars are null)...
I'm thinking now that that's not the right thing. These
should be set (added) no matter what.
The reason for the current behavior is so that people can "overrule"
the setti
