Re: cvs commit: apr/build apr_common.m4

2003-03-07 Thread Joe Orton
On Fri, Mar 07, 2003 at 12:12:43PM -, Jeff Trawick wrote: > -dnl APR_CHECK_APR_DEFINE( symbol, path_to_apr ) > +dnl APR_CHECK_APR_DEFINE( symbol ) >dnl >AC_DEFUN(APR_CHECK_APR_DEFINE,[ > -AC_EGREP_CPP(YES_IS_DEFINED, [ > -#include "$2/include/apr.h" > -#if $1 > -YES_IS_D

Re: cvs commit: apr/build apr_common.m4

2002-08-22 Thread Greg Stein
On Thu, Aug 22, 2002 at 08:34:17PM -, [EMAIL PROTECTED] wrote: > gstein 2002/08/22 13:34:16 >... > * change the default APR layout to support parallel installation; > rename the old layout to "classic" Note that I put this back to the default, after Thom's/Justin's changes moved t

Re: cvs commit: apr/build apr_common.m4 rules.mk.in

2002-08-19 Thread Justin Erenkrantz
On Mon, Aug 19, 2002 at 06:33:10AM -, [EMAIL PROTECTED] wrote: > jerenkrantz2002/08/18 23:33:10 > > Modified:.CHANGES apr-config.in config.layout configure.in >buildapr_common.m4 rules.mk.in > Log: > - Add parallel-apr layout which confines the 'parall

Re: cvs commit: apr/build apr_common.m4

2002-05-14 Thread Justin Erenkrantz
On Tue, May 14, 2002 at 09:28:03AM +0100, Thom May wrote: > * [EMAIL PROTECTED] ([EMAIL PROTECTED]) wrote : > > jerenkrantz02/05/14 00:35:58 > > > > Modified:buildapr_common.m4 > > Log: > > Add APR_MKDIR_P_CHECK macro based on httpd-2.0's APACHE_MKDIR_P_CHECK. > > > > Revisi

Re: cvs commit: apr/build apr_common.m4

2002-05-14 Thread Thom May
* [EMAIL PROTECTED] ([EMAIL PROTECTED]) wrote : > jerenkrantz02/05/14 00:35:58 > > Modified:buildapr_common.m4 > Log: > Add APR_MKDIR_P_CHECK macro based on httpd-2.0's APACHE_MKDIR_P_CHECK. > > Revision ChangesPath > 1.32 +20 -0 apr/build/apr_common.m4 Are

Re: cvs commit: apr/build apr_common.m4

2002-03-14 Thread Aaron Bannert
On Wed, Mar 13, 2002 at 06:13:02PM -, [EMAIL PROTECTED] wrote: > jim 02/03/13 10:13:02 > > Modified:buildapr_common.m4 > Log: > Fix weird error report... not sure what > brain damaged shell would misinterpret the current method, but > this safes it. > > Revision

Re: cvs commit: apr/build apr_common.m4

2002-03-14 Thread Jim Jagielski
I'm following up... Greg Stein wrote: > > On Thu, Mar 14, 2002 at 12:50:43PM +1000, Brian Havard wrote: > > On Wed, 13 Mar 2002 20:41:12 -0500 (EST), Jim Jagielski wrote: > > > > >Weird... I'm guessing you don't have problems with the other > > >usages of ${}... $3 should be special enough not

Re: cvs commit: apr/build apr_common.m4

2002-03-14 Thread Greg Stein
On Thu, Mar 14, 2002 at 12:50:43PM +1000, Brian Havard wrote: > On Wed, 13 Mar 2002 20:41:12 -0500 (EST), Jim Jagielski wrote: > > >Weird... I'm guessing you don't have problems with the other > >usages of ${}... $3 should be special enough not to require. > >I'll back this out since shells that *

Re: cvs commit: apr/build apr_common.m4

2002-03-14 Thread Brian Havard
On Wed, 13 Mar 2002 20:41:12 -0500 (EST), Jim Jagielski wrote: >Weird... I'm guessing you don't have problems with the other >usages of ${}... $3 should be special enough not to require. >I'll back this out since shells that *don't* support it >are more broken :) Thanks (wow, that was quick :) Is

Re: cvs commit: apr/build apr_common.m4

2002-03-14 Thread Jim Jagielski
Weird... I'm guessing you don't have problems with the other usages of ${}... $3 should be special enough not to require. I'll back this out since shells that *don't* support it are more broken :) Brian Havard wrote: > > On 13 Mar 2002 18:13:02 -, [EMAIL PROTECTED] wrote: > > >jim 02

Re: cvs commit: apr/build apr_common.m4

2002-03-14 Thread Brian Havard
On 13 Mar 2002 18:13:02 -, [EMAIL PROTECTED] wrote: >jim 02/03/13 10:13:02 > > Modified:buildapr_common.m4 > Log: > Fix weird error report... not sure what > brain damaged shell would misinterpret the current method, but > this safes it. > > Revision ChangesPath >

Re: cvs commit: apr/build apr_common.m4

2001-07-05 Thread Jeff Trawick
Justin Erenkrantz <[EMAIL PROTECTED]> writes: > On Thu, Jul 05, 2001 at 12:02:10AM -, [EMAIL PROTECTED] wrote: > > trawick 01/07/04 17:02:10 > > > > Modified:.configure.in > >buildapr_common.m4 > > Log: > > Stop trying to provide cross-process pthread

Re: cvs commit: apr/build apr_common.m4

2001-07-05 Thread Justin Erenkrantz
On Thu, Jul 05, 2001 at 12:02:10AM -, [EMAIL PROTECTED] wrote: > trawick 01/07/04 17:02:10 > > Modified:.configure.in >buildapr_common.m4 > Log: > Stop trying to provide cross-process pthread mutexes on systems where > the form of shared memory used

Re: cvs commit: apr/build apr_common.m4 apr_hints.m4 apr_network.m4 rules.mk.in

2001-04-06 Thread jean-frederic clere
[EMAIL PROTECTED] wrote: [cut] > 1.4 +4 -3 apr/build/rules.mk.in > > Index: rules.mk.in > === > RCS file: /home/cvs/apr/build/rules.mk.in,v > retrieving revision 1.3 > retrieving revision 1.4 > diff -u -r1.3 -

Re: cvs commit: apr/build apr_common.m4

2001-02-27 Thread Karl Fogel
Greg Stein <[EMAIL PROTECTED]> writes: > Not entirely true. It worked splendidly on my Linux box (otherwise, I > wouldn't have committed :-). I should have said "the build was broken on at least some BSD and some Linux systems". :-) -K

Re: cvs commit: apr/build apr_common.m4

2001-02-27 Thread Greg Stein
On Tue, Feb 27, 2001 at 08:48:22PM -, [EMAIL PROTECTED] wrote: >... > However, since the build was broken on at least BSD and Linux, and > Jim's patch makes things work again, it seemed better to apply it and > *then* figure out if it's the Right Thing. :-) Not entirely true. It worked s

Re: cvs commit: apr/build apr_common.m4

2001-02-27 Thread Jim Jagielski
Greg Stein wrote: > > No way. There is zero advantage to doing that. We *are* using > AC_CHECK_HEADERS' for-loop, so I'm not sure what you're talking about. That was before I saw the current rev... Agreed it doesn't make sense now :) > The M4 thing is an unrolled recursion over > a list, basical

Re: cvs commit: apr/build apr_common.m4

2001-02-27 Thread Greg Stein
On Tue, Feb 27, 2001 at 07:45:18AM -0500, Jim Jagielski wrote: > [EMAIL PROTECTED] wrote: >... > > * configure.in: just call APR_FLAG_HEADERS once. This allows autoconf to > > loop over the values *once* rather than substituting N loops for header > > checking. This drops configure's size

Re: cvs commit: apr/build apr_common.m4

2001-02-27 Thread Jim Jagielski
Jeff Trawick wrote: > > now APR on Tru64 doesn't think it has stdio.h (sort of; configure > output says we found it; APR_HAVE_STDIO_H is set to zero); a few other > header files aren't substituted properly either... work-around > forthcoming... > > yes, this is with a virgin configure.in with no

Re: cvs commit: apr/build apr_common.m4

2001-02-27 Thread Jeff Trawick
[EMAIL PROTECTED] writes: > gstein 01/02/27 03:34:50 > > Modified:.configure.in >buildapr_common.m4 > Log: > * configure.in: just call APR_FLAG_HEADERS once. This allows autoconf to > loop over the values *once* rather than substituting N loops for h

Re: cvs commit: apr/build apr_common.m4

2001-02-27 Thread Jim Jagielski
[EMAIL PROTECTED] wrote: > > gstein 01/02/27 03:34:50 > > Modified:.configure.in >buildapr_common.m4 > Log: > * configure.in: just call APR_FLAG_HEADERS once. This allows autoconf to > loop over the values *once* rather than substituting N loops for