RE: [PATCH] Get dependency generation working with VPATH

2002-04-18 Thread Sander Striker
> From: Justin Erenkrantz [mailto:[EMAIL PROTECTED] > Sent: 18 April 2002 20:05 > To: dev@apr.apache.org > Subject: [PATCH] Get dependency generation working with VPATH > > > Since this is a fairly large patch, I'll post it first to give > people a chance to comment. > > This attempts to get "ma

[PATCH] Get dependency generation working with VPATH

2002-04-18 Thread Justin Erenkrantz
Since this is a fairly large patch, I'll post it first to give people a chance to comment. This attempts to get "make depend" working when using VPATH. Since we rely on $(srcdir) to always be defined, I'm adding srcdir and VPATH to all Makefiles. This also has the (good) side-effect of making th

Re: [PATCH] apr_atomic.h on Linux

2002-04-18 Thread Cliff Woolley
On Thu, 18 Apr 2002, Justin Erenkrantz wrote: > I committed this second part as with that testatomic passes here > on my Linux/SMP box. It passed for me beforehand on my non-SMP linux box, but it still passes afterward, so +1 on that commit. --Cliff

Re: [PATCH] apr_atomic.h on Linux

2002-04-18 Thread Justin Erenkrantz
On Thu, Apr 18, 2002 at 01:58:29PM +0100, Joe Orton wrote: > The mutex-based apr_atomic.c code looks like it hasn't really been > finished, but with this patch, the "testatomic" passes except for a "no > surprise" result which I presume is supposed to happen. (without the > patch ATOMIC_HASH coul

Re: [PATCH] apr_atomic.h on Linux

2002-04-18 Thread Ian Holsman
Justin Erenkrantz wrote: On Thu, Apr 18, 2002 at 12:36:08PM -0400, Cliff Woolley wrote: On Thu, 18 Apr 2002, Joe Orton wrote: Sure - I'd just hope the change could be made for the time being, until someone gets round to that, since currently APR won't build on combinations of modern glibc/kernel.

Re: [PATCH] apr_atomic.h on Linux

2002-04-18 Thread Justin Erenkrantz
On Thu, Apr 18, 2002 at 12:36:08PM -0400, Cliff Woolley wrote: > On Thu, 18 Apr 2002, Joe Orton wrote: > > > Sure - I'd just hope the change could be made for the time being, until > > someone gets round to that, since currently APR won't build on > > combinations of modern glibc/kernel. > > Whic

Re: apr file questions

2002-04-18 Thread Stas Bekman
Cliff Woolley wrote: On 18 Apr 2002, Jeff Trawick wrote: Since APR_EOF is one of the errors you might get back from apr_file_read(), I agree with Jeff. This: while (apr_file_read(file, buffer, &len) != APR_SUCCESS) { ... } is probably preferable. You'll most l

Re: apr file questions

2002-04-18 Thread Jon Travis
On Thu, Apr 18, 2002 at 10:40:12AM -0400, Cliff Woolley wrote: > On 18 Apr 2002, Jeff Trawick wrote: > > Since APR_EOF is one of the errors you might get back from > apr_file_read(), I agree with Jeff. This: > > > > while (apr_file_read(file, buffer, &len) != APR_SUCCESS) > > >

Re: [PATCH] apr_atomic.h on Linux

2002-04-18 Thread Cliff Woolley
On Thu, 18 Apr 2002, Joe Orton wrote: > Sure - I'd just hope the change could be made for the time being, until > someone gets round to that, since currently APR won't build on > combinations of modern glibc/kernel. Which combinations? It works fine for me on glibc 2.2.5 / linux 2.4.18. Granted,

Re: [PATCH] apr_atomic.h on Linux

2002-04-18 Thread Joe Orton
On Thu, Apr 18, 2002 at 08:38:31AM -0700, Brian Pane wrote: > Joe Orton wrote: > > >There are issues with use of asm/atomic.h on Linux: according to the > >kernel gurus here this is a header for internal use of the kernel, > >and shouldn't be used from userspace. > > > >The problems are, if I unde

Re: Problem with child reaping on Tru64

2002-04-18 Thread Jim Jagielski
> Jim Jagielski <[EMAIL PROTECTED]> writes: > > > Just my 2cents; you'll do want you want. That did *not* come out right... :) -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ "A socie

Re: [PATCH] apr_atomic.h on Linux

2002-04-18 Thread Brian Pane
Joe Orton wrote: There are issues with use of asm/atomic.h on Linux: according to the kernel gurus here this is a header for internal use of the kernel, and shouldn't be used from userspace. The problems are, if I understand them correctly: - with newer kernel/glibc combinations (e.g the RHL7.3 bet

Re: Problem with child reaping on Tru64

2002-04-18 Thread Jeff Trawick
Jim Jagielski <[EMAIL PROTECTED]> writes: > AFAIK no one else has described the same problem, so I'd be > hesistant about making it the default on systems that define > SA_NOCLDWAIT and aren't tru64. We may tickle something that we > may not want to be messing with. Can somebody besides me and Da

Re: Problem with child reaping on Tru64

2002-04-18 Thread Jim Jagielski
AFAIK no one else has described the same problem, so I'd be hesistant about making it the default on systems that define SA_NOCLDWAIT and aren't tru64. We may tickle something that we may not want to be messing with. Just my 2cents; you'll do want you want. Jeff Trawick wrote: > > This patch loo

Re: apr file questions

2002-04-18 Thread Jeff Trawick
Stas Bekman <[EMAIL PROTECTED]> writes: > Jeff Trawick wrote: > > Stas Bekman <[EMAIL PROTECTED]> writes: > > > >>2. What's the idiomatic apr read till eof? From grepping the source > >>code, I see apr_file_eof is hardly ever used. Is something wrong with: > >> > >> while (!apr_file_eof(fp

Re: Problem with child reaping on Tru64

2002-04-18 Thread Jeff Trawick
Dave Hill <[EMAIL PROTECTED]> writes: > Hi all, > I have run into a problem on Compaq Tru64 with cgi processes > being reaped when using with mpm worker. > > I had always thought the signal(SIGCHLD,SIG_IGN) would always > cause child processes to quietly go away but This patc

Re: apr file questions

2002-04-18 Thread Cliff Woolley
On 18 Apr 2002, Jeff Trawick wrote: Since APR_EOF is one of the errors you might get back from apr_file_read(), I agree with Jeff. This: > > while (apr_file_read(file, buffer, &len) != APR_SUCCESS) > > { > > ... > > } is probably preferable. You'll most l

Re: apr file questions

2002-04-18 Thread Stas Bekman
Jeff Trawick wrote: Stas Bekman <[EMAIL PROTECTED]> writes: 2. What's the idiomatic apr read till eof? From grepping the source code, I see apr_file_eof is hardly ever used. Is something wrong with: while (!apr_file_eof(fp)) { rc = apr_file_read(fp, buf, &nbytes); .

Re: [patch unix/readwrite.c] a bug fix for apr_file_read

2002-04-18 Thread Jeff Trawick
Stas Bekman <[EMAIL PROTECTED]> writes: > without this patch, while(!apr_file_eof(...)) spins for unbuffered > fh. ... Committed... Thanks! -- Jeff Trawick | [EMAIL PROTECTED] Born in Roswell... married an alien...

Re: apr file questions

2002-04-18 Thread Jeff Trawick
Stas Bekman <[EMAIL PROTECTED]> writes: > 2. What's the idiomatic apr read till eof? From grepping the source > code, I see apr_file_eof is hardly ever used. Is something wrong with: > > while (!apr_file_eof(fp)) { > rc = apr_file_read(fp, buf, &nbytes); > ... >

Re: [PATCH] apr_atomic.h on Linux

2002-04-18 Thread Joe Orton
On Thu, Apr 18, 2002 at 01:58:29PM +0100, Joe Orton wrote: > There are issues with use of asm/atomic.h on Linux: according to the > kernel gurus here this is a header for internal use of the kernel, > and shouldn't be used from userspace. > > The problems are, if I understand them correctly: > >

[PATCH] apr_atomic.h on Linux

2002-04-18 Thread Joe Orton
There are issues with use of asm/atomic.h on Linux: according to the kernel gurus here this is a header for internal use of the kernel, and shouldn't be used from userspace. The problems are, if I understand them correctly: - with newer kernel/glibc combinations (e.g the RHL7.3 beta) this stuff r

Re: [PATCH] Cleanly enable VPATH builds

2002-04-18 Thread Justin Erenkrantz
On Wed, Apr 17, 2002 at 10:17:07PM +0100, Thom May wrote: > Hi, > currently to do a vpath build you have to create certain directories in > directory that you wish to build in, ie: > build/ > srclib/{apr,apr-util,pcre,expat-lite} > docs/conf > > This patch enables you to create a clean directory a

Re: Split paths portability

2002-04-18 Thread William A. Rowe, Jr.
At 10:29 PM 4/17/2002, you wrote: William A. Rowe, Jr. wrote: While we consider Stas' ideas for a portable tmpdir, we should also consider breaking apart path strings (such as env('PATH'), or LIB or INCLUDE paths as well.) These semantics change considerably from Win32 to unix and other platforms.

Re: Split paths portability

2002-04-18 Thread Stas Bekman
William A. Rowe, Jr. wrote: While we consider Stas' ideas for a portable tmpdir, we should also consider breaking apart path strings (such as env('PATH'), or LIB or INCLUDE paths as well.) These semantics change considerably from Win32 to unix and other platforms. I dunno what NetWare does here,