Re: Fix build on amd64 platform by importing new config.{guess,sub}

2004-02-18 Thread Craig Rodrigues
On Tue, Feb 17, 2004 at 10:00:25PM +, Joe Orton wrote: Thanks for looking at this Craig. I notice you have left he conflicting matches in the case statements, e.g. *:OS390:*:* | *:OS/390:*:*) echo s390-ibm-os390 and then *:OS/390:*:*) echo i370-ibm-openedition

Re: apr/apr-util python dependence

2004-02-18 Thread Justin Erenkrantz
--On Sunday, February 15, 2004 1:06 PM -0500 Jeff Trawick [EMAIL PROTECTED] wrote: I'd guess that a conversion to the less cool but more widely ported/precompiled/preinstalled P* scripting language would be a rather quick and would not suffer greatly from uncoolness and would pick up additional

Re: apr/apr-util python dependence

2004-02-18 Thread Sascha Schumann
requiring automake is not something I personally would be excited about... I'd like to see how bad a conversion to ordinary sh would turn out.. also, I'd guess that a conversion to the less cool but more widely ported/precompiled/preinstalled P* scripting language would be a rather quick

Re: Solving the off_t problem in APR 1.0

2004-02-18 Thread William A. Rowe, Jr.
At 03:31 AM 2/17/2004, Ben Reser wrote: On Wed, Feb 04, 2004 at 03:22:17PM +, Joe Orton wrote: On Mon, Feb 02, 2004 at 05:19:09PM -0800, Ben Reser wrote: On Wed, Jan 28, 2004 at 04:45:26PM -0800, Ben Reser wrote: So I guess I'll look into redoing it to use int, long or long long

Re: apr/apr-util python dependence

2004-02-18 Thread Joe Orton
On Wed, Feb 18, 2004 at 08:22:56AM +0100, Sascha Schumann wrote: requiring automake is not something I personally would be excited about... I'd like to see how bad a conversion to ordinary sh would turn out.. also, I'd guess that a conversion to the less cool but more widely

Re: Fix build on amd64 platform by importing new config.{guess,sub}

2004-02-18 Thread Jeff Trawick
Joe Orton wrote: Thanks for looking at this Craig. I notice you have left he conflicting matches in the case statements, e.g. *:OS390:*:* | *:OS/390:*:*) echo s390-ibm-os390 and then *:OS/390:*:*) echo i370-ibm-openedition exit 0 ;; this is really the problem which

Re: Fix build on amd64 platform by importing new config.{guess,sub}

2004-02-18 Thread Joe Orton
On Wed, Feb 18, 2004 at 05:17:38AM -0500, Jeff Trawick wrote: Joe Orton wrote: Thanks for looking at this Craig. I notice you have left he conflicting matches in the case statements, e.g. *:OS390:*:* | *:OS/390:*:*) echo s390-ibm-os390 and then *:OS/390:*:*)

Re: apr/apr-util python dependence

2004-02-18 Thread Sascha Schumann
The subject is whether Python can be required for running buildconf, not for running configure make. I don't see a problem requiring Python for buildconf. The problem with python is that it is an exotic language and hardly installed anywhere (not everyone runs Linux). Just

Re: apr/apr-util python dependence

2004-02-18 Thread Greg Stein
On Wed, Feb 18, 2004 at 10:13:51AM +, Joe Orton wrote: On Wed, Feb 18, 2004 at 08:22:56AM +0100, Sascha Schumann wrote: requiring automake is not something I personally would be excited about... I'd I'd -1 it right off the bat. No way on automake. like to see how bad a conversion

Re: apr/apr-util python dependence

2004-02-18 Thread Brian W. Fitzpatrick
On Wed, 2004-02-18 at 05:13, Sascha Schumann wrote: Automake is clearly not a choice, nor has it ever been for a project of considerable size. And recursive make clearly sucks -- the PHP project got rid of it 2 years ago. We agree on these points. +1 It was also written

Re: apr/apr-util python dependence

2004-02-18 Thread Sascha Schumann
As part of the configure process, I would agree with you, but as part of buildconf, I disagree--not everyone needs to run buildconf--only developers, and if you're a developer, it's *really* not asking that much to have Python on your dev box. That must be a wonderful world where you run

Re: Fix build on amd64 platform by importing new config.{guess,sub}

2004-02-18 Thread Jeff Trawick
Joe Orton wrote: On Wed, Feb 18, 2004 at 05:17:38AM -0500, Jeff Trawick wrote: Joe Orton wrote: Thanks for looking at this Craig. I notice you have left he conflicting matches in the case statements, e.g. *:OS390:*:* | *:OS/390:*:*) echo s390-ibm-os390 and then *:OS/390:*:*) echo

Re: Solving the off_t problem in APR 1.0

2004-02-18 Thread Ben Reser
On Tue, Feb 17, 2004 at 01:15:12PM -0600, William A. Rowe, Jr. wrote: I am against changing the default size or alignment of any data type in APR_0_9_BRANCH. If this [has] happened we break all binary compat. Umm we've been careful to avoid doing exactly that. The point here isn't to change

Re: Solving the off_t problem in APR 1.0

2004-02-18 Thread William A. Rowe, Jr.
At 12:48 PM 2/18/2004, Ben Reser wrote: On Tue, Feb 17, 2004 at 01:15:12PM -0600, William A. Rowe, Jr. wrote: I am against changing the default size or alignment of any data type in APR_0_9_BRANCH. If this [has] happened we break all binary compat. Umm we've been careful to avoid doing

Re: Fix build on amd64 platform by importing new config.{guess,sub}

2004-02-18 Thread Brian Havard
On Wed, 18 Feb 2004 10:41:33 +, Joe Orton wrote: On Wed, Feb 18, 2004 at 05:17:38AM -0500, Jeff Trawick wrote: Joe Orton wrote: Thanks for looking at this Craig. I notice you have left he conflicting matches in the case statements, e.g. *:OS390:*:* | *:OS/390:*:*) echo

Re: Fix build on amd64 platform by importing new config.{guess,sub}

2004-02-18 Thread Joe Orton
On Thu, Feb 19, 2004 at 09:11:40AM +1000, Brian Havard wrote: Some of these platforms are probably already broken with the new gen-build changes since build-outputs.mk doesn't know about $(OSDIR). Yeah, I noticed the build was broken on OS/2, tries to compile dso/unix/dso.c. So how do you