Next will be to migrate to APR_FLAGS_FUNCS... will do a bit
later.
--
===
Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/
"Hell is hot, that's never been disputed by anybody."
I've got a real cool idea about how to make everyone happy...
Heading out right now, but will commit something later
today :)
--
===
Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/
"Hell is
[EMAIL PROTECTED] wrote:
>
>
> I like APR_FLAG_HEADERS personally. I like the idea of having configure
> just detect the variable name, but that means documenting what the
> transformations are, and it keeps us from having control over the variable
> name, which I kind of dislike.
>
It also, h
I like APR_FLAG_HEADERS personally. I like the idea of having configure
just detect the variable name, but that means documenting what the
transformations are, and it keeps us from having control over the variable
name, which I kind of dislike.
Ryan
On Mon, 26 Feb 2001, Cliff Woolley wrote:
>
Cliff Woolley wrote:
>
> It also wouldn't hurt my feelings any if APR_CHECK_HEADERS automagically
> determined the variable name to flag with a 1 or a 0 by doing basically
> this
>s/\//_/g;
>s/\.//g;
> on the header name. Hence "sys/sendfile.h" becomes the flag variable
> "sys_sendfileh"
On Mon, 26 Feb 2001, Jim Jagielski wrote:
> > Use APR_CHECK_HEADERS instead
> >
>
> Before I go any further, I want to rethink the name. Maybe APR_FLAG_HEADERS
> (want to avoid confusion here) or APR_HEADERS_SET. Suggestions
> welcome.
APR_CHECK_HEADERS doesn't bother me... it makes it clea
[EMAIL PROTECTED] wrote:
>
> jim 01/02/26 11:56:14
>
> Modified:.configure.in
> Log:
> Use APR_CHECK_HEADERS instead
>
Before I go any further, I want to rethink the name. Maybe APR_FLAG_HEADERS
(want to avoid confusion here) or APR_HEADERS_SET. Suggestions
welcome.
On Mon, 26 Feb 2001, Jim Jagielski wrote:
> Any interest in my adding something like AC_CHECK_HEADERS_FLAG
> which implements the below:
>
> >AC_CHECK_HEADERS(sys/signal.h, sys_signalh="1", sys_signalh="0")
>
> AC_CHECK_HEADERS_FLAG(sys/signal.h, sys_signalh)
>
> we seem to use this const
Any interest in my adding something like AC_CHECK_HEADERS_FLAG
which implements the below:
>AC_CHECK_HEADERS(sys/signal.h, sys_signalh="1", sys_signalh="0")
AC_CHECK_HEADERS_FLAG(sys/signal.h, sys_signalh)
we seem to use this construct enough...
--
Cliff Woolley wrote:
>
> On 26 Feb 2001, Ben Collins-Sussman wrote:
>
> > #if APR_HAVE_SYS_SENDFILE_H
> > #include
> > #endif
> >
> > And, of course, my system has no . :)
> >
> > I know that there's been a recent thread on this list about
> > sendfile.h, but I have to admit that I didn't read
[EMAIL PROTECTED] writes:
> rbb 01/02/26 08:44:39
>
> Modified:.configure.in
> Log:
> Fix the sendfile handling in APR. We have to subst the sys_sendfileh
> variable into apr.h.
Thanks... I have no explanation for why I left this off earlier.
(If my init process wa
Fix is on the way. The problem is that we never subst into the apr.h
file, so APR_HAS_SENDFILE_H is defined to be @has_sendfile@ or something
like it.
Ryan
On 26 Feb 2001, Ben Collins-Sussman wrote:
>
> I just removed my apr/ subdir and checked it out fresh this morning.
> I'm getting this com
On 26 Feb 2001, Ben Collins-Sussman wrote:
> #if APR_HAVE_SYS_SENDFILE_H
> #include
> #endif
>
> And, of course, my system has no . :)
>
> I know that there's been a recent thread on this list about
> sendfile.h, but I have to admit that I didn't read it. (*blush*) Can
> anyone tell me what t
I just removed my apr/ subdir and checked it out fresh this morning.
I'm getting this compile error on my FreeBSD 4.2 system:
gmake[4]: Entering directory
`/usr/home/sussman/projects/subversion/apr/network_io/unix'
/bin/sh /usr/home/sussman/projects/subversion/apr/libtool --mode=compile
--silen
> Log:
> Begin to move functions from the http module to the core. The goal is to
> have only functions that are HTTP specific in the http directory.
This is going to be a long process, and I am likely to get some stuff
wrong. The goal is to allow us to really be multi-protocol. Right no
On Sun, 25 Feb 2001, Wan-Teh Chang wrote:
> If an APR client needs the same test, you might want
> to look into why APR fails to make the test unnecessary
> for its clients. For example, the apr_dso_* functions
> should make the tests for HAVE_DL_H and HAVE_DLFCN_H
> unnecessary for APR clients.
On Sun, 25 Feb 2001, Wan-Teh Chang wrote:
> [EMAIL PROTECTED] wrote:
> >
> > Fair enough. So let me tone down what I said to simply, "If an APR client
> > might reasonbly need the same test, we should export our test result."
> > +1 for using Apache and Subversion as good places to look for an in
[EMAIL PROTECTED] wrote:
>
> Fair enough. So let me tone down what I said to simply, "If an APR client
> might reasonbly need the same test, we should export our test result."
> +1 for using Apache and Subversion as good places to look for an initial
> definition of what's "reasonable."
If an APR
From: "dean gaudet" <[EMAIL PROTECTED]>
Sent: Sunday, February 25, 2001 7:42 PM
> i'm a bit of an I18N novice, but doesn't it all just magically work if you
> use UTF-8 encoding everywhere?
>
> UTF-8 deliberately avoids using \0 and / in the encodings. plain ascii
> works unmodified. unix files
On Sun, 25 Feb 2001 [EMAIL PROTECTED] wrote:
> > Right now I'm trying to
> > figure out a respectably clean way to implement bucket reuse lists to cut
> > down on mallocs/frees.
>
> Quick question on this. How bad is the malloc/free problem now? I agree
> the empty bucket list is a good thing, j
i'm a bit of an I18N novice, but doesn't it all just magically work if you
use UTF-8 encoding everywhere?
UTF-8 deliberately avoids using \0 and / in the encodings. plain ascii
works unmodified. unix filesystems generally support UTF-8 directly
(because of the \0 and / avoidance).
this allows y
On Sun, 25 Feb 2001 [EMAIL PROTECTED] wrote:
> (Assuming OtherBill's message was supposed to go to the list, not just to
> me...)
>
> On Sun, 25 Feb 2001, William A. Rowe, Jr. wrote:
>
> > > At least all of the HAVE_foo_H ones, I'd think. If there's a reasonable
> > > chance an APR client will ne
(Assuming OtherBill's message was supposed to go to the list, not just to
me...)
On Sun, 25 Feb 2001, William A. Rowe, Jr. wrote:
> > At least all of the HAVE_foo_H ones, I'd think. If there's a reasonable
> > chance an APR client will need to do the same autoconf test, we might as
> > well sa
On Sun, 25 Feb 2001 [EMAIL PROTECTED] wrote:
> > At least all of the HAVE_foo_H ones, I'd think. If there's a reasonable
> > chance an APR client will need to do the same autoconf test, we might as
> > well save them the trouble. Header tests pretty easily fall into that
> > category.
>
> I disa
On Sun, 25 Feb 2001 [EMAIL PROTECTED] wrote:
> On Sun, 25 Feb 2001, William A. Rowe, Jr. wrote:
>
> > The question is which of these are worth exporting publicly. I don't have
> > a fast or simple answer. So I'm just tossing the list at the list.
>
> At least all of the HAVE_foo_H ones, I'd thin
On Sun, 25 Feb 2001, William A. Rowe, Jr. wrote:
> The question is which of these are worth exporting publicly. I don't have
> a fast or simple answer. So I'm just tossing the list at the list.
At least all of the HAVE_foo_H ones, I'd think. If there's a reasonable
chance an APR client will ne
Jeff... thanks for banging your head against 2.0 for us all.
I took a look at the 'private' old HAVE_* subset, listed below;
HAVE_DL_H
HAVE_DLFCN_H
HAVE_GRP_H
HAVE_HSTRERROR
HAVE_ICONV_H
HAVE_LANGINFO_H
HAVE_PWD_H
HAVE_MALLOC_H
HAVE_STDDEF_H
HAVE_SYS_FCNTL_H
HAVE_SYS_FILE_H
HAVE_SYS_MMAN_H
HAVE_
27 matches
Mail list logo
