Complete.Org: Mailing Lists: Archives: freeciv-dev: September 1999:
Re: [Freeciv-Dev] Revised patch supporting BeOS for freeciv (PR#122)
Home

Re: [Freeciv-Dev] Revised patch supporting BeOS for freeciv (PR#122)

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: jrb3@xxxxxxxx
Cc: freeciv-dev@xxxxxxxxxxx, bugs@xxxxxxxxxxxxxxxxxxx
Subject: Re: [Freeciv-Dev] Revised patch supporting BeOS for freeciv (PR#122)
From: David Pfitzner <dwp@xxxxxxxxxxxxxx>
Date: Thu, 2 Sep 1999 18:00:58 +1000 (EST)

jrb3@xxxxxxxx wrote:

>       Okay, friends, I've taken Dave Pfitzner's kind advice and produced
> a better patch off the top of the CVS tree.  The patch follows, as straight
> output from `cvs -z3 diff -c`,

("diff -u" is prefered if available)

> minus the diffs for the top-level configure.
> The responsible party will need to regenerate configure for me -- I've only
> got a mid-June GeekGadgets autoconf, and it generates several thousand lines
> of differences for configure.  (The patch shows the proper revision numbers
> for the 'source' files.)

Yeah, thats probably the usual problem that configure includes
script line numbers in some of its echo statements, so if you
add/substract some lines earlier in the file they all change :-/
In any case not including the auto-generated changes is usually
preferable.

>       I hit some real weirdnesses while doing this, though.  PACKAGE and
> VERSION got defined to 1, prompting the aclocal.m4 change.

Strange.  Don't know what the problem is, but that change probably
won't work because aclocal.m4 is auto-generated...

>  config.h.in and 
> configure.in changed to handle the new indicator SOCKET_ZERO_ISNT_STDIN.
> configure.in also got some other BeOS-specific changes that I figured out
> how to make happen there;  it's a little gross, so don't look at it hard. :-)
> And, of course, server/sernet.c which actually uses SOCKET_ZERO_ISNT_STDIN
> to operate correctly when socket zero isn't stdin.  Works, too. :-o :-D
> (BeOS R4 x86)

Um, sorry to say, but I'm not that thrilled about the uname stuff :-/
Partly, I suspect if one is going to look for specific systems one 
should rather use config.guess (an autoconf provided script), 
although we haven't found that necessary so far.  But the real 
problem is that uname, or config.guess (or #ifdef __BEOS__ for 
that matter) subvert a principle goal of configure, which is to 
test for _features_ not systems.  That way, if for example some 
later BeOS release does some things differently, configure may 
have more chance of doing the right thing.

On the other hand maybe we can live with this, and/or #ifdef __BEOS__
changes...

BTW, does BeOS have a getuid() function at all?  If not, we
could check that instead in dont_run_as_root().  (The problem
with doing this in general is systems which include it as a 
dummy function.)

-- David

[Prev in Thread] Current Thread [Next in Thread]