netrek-server osx-branch compiles
I’ve gotten netrek-server 2.15 ported to osx. It compiles clean, I even cleaned up the warnings.
I’m building everything in ntserv, newstartd, robots, robotd, tools, sequencer, keycomp, xsg, and pledit.
I was informed gum is no longer maintained? (if so, remove it from darcs?)
I prefer to work in bzr and would like to continue working there until we know that the osx code is stable and ready for merge back into upsteam/darcs.
The branch is hosted on launchpad: bzr branch lp:~tanner/netrek-server/osx-branch
Web view: https://code.launchpad.net/~tanner/netrek-server/osx-branch
I did alot of clean-up as I went.
#ifdef and macros for platforms and operating systems from the ancient past I refactored and just put in the equivalent (generally speaking) POSIX API calls. Example sun3? sun4? sequent? bzero vs memset? string.h vs strings.h?
What I would like to do is open a launchpad bug for each major “drop” of an old platform and allow the developers to discuss it.
I also removed most (all?) of the deprecated APIs, as hinted above, memcmp vs bcmp, memcpy vs bcopy, memset vs bzero. Like above, I’ll open a LP bugs and let the developers discuss.
Other clean ups:
* SYSV signals vs BSD signals
* Header file inclusions unistd.h? strings.h? stdlib.h? fctl.h?
* strcpy, strncpy, string stuff in general
* random, srandom vs rrandom,ssrandom
* usleep vs micosleep
Everyone think using LP bugs to discuss the changes is a good methodology for tracking all of this?
I purposely left out how to build the branch, the tools I used, and what not, as I did not start on a pristine osx install. I’m am currently working on documenting everything and will put something on the wiki when I think I have something that won’t cause more problems then it solves.
Right now, I’m just looking to start the discussion, let developers use tools they know (vim, emacs, etc) and give me a code review.
Right now I’ve gotten the netrek-server to compile using the following #defines (ignore the format for now):
“-DSERVER”
“-DFEATURES”
“-DFEATURE_PACKETS”
“-DPING”
“-DRCD”
“-DCHECKMESG”
“-DPRETSERVER”
I found that without out these “core” #defines the code will not compile unless someone goes into the .c files and makes sure the:
#ifdef BLAH
…
#endif
All match with the config.h.in definitions. I did not think it was worth the effort 
First question, are the above #define reasonable?
Second question, what other #define are typical?
There are so many #define in config.h.in all the code/compilation paths are unreasonable to test.
I’d like a “good” set of #defines in addition to the ones listed above.