[crossfire] Crossfire server code cleanup/janitorial

[Kevin Zheng]

On 04/21/2014 04:20, Tolga Dalman wrote:
> My impression about crossfire right now is that the development in
> the server and client code is pretty dormant for the last few years.
> At the same time, however, I notice some increased activity towards
> cleanup work. I want to take this impetus as a reason to contribute
> by myself.

More help with Crossfire is always welcome.

> Two reasons are holding me currently up to contribute, in fact: 1.
> There is no roadmap or "vision". Admittedly, crossfire runs pretty
> fine for ages now, nevertheless, I do see some open issues. 2. Parts
> of the code is crufty and even messy. To be honest, I'm scared off 
> fixing issues I find in the code because of this.

Having a roadmap or vision is a good idea. Right now mine is to make
sure the game works on my operating system and keep it that way. My
other vision is to make Crossfire more fun, but without any
crystallization that's not very productive.

I have many, many open issues with Crossfire, but I haven't considered
them important enough to dedicate substantial work to them yet. I'd love
to hear your issues so we can start discussing and working on those
right now.

> 1. Define clear requirements for the crossfire server code (this
> might apply to the client as well). From this thread, I found out
> that the major platforms are Linux, BSD, MacOS X, Solaris, and Win32.
> What I'm still missing is the versions. Something like this would be
> nice: - For Linux I would just define the use of GCC 4.6 or higher, 
> binutils 2.20 or higher, glibc 2.16 or higher. - For Win32 I would
> require Visual Studio 12 or higher - ... Naturally, these
> requirements should be testable by the developers. Practically, these
> items are added in the README file and perhaps published on the
> crossfire web site.

The problem with drawing a bright line is that somebody is inevitably
left on the other side. Many working groups have drawn a standard called
C99; we do not have to rigidly adhere to it, but instead of requiring
specific versions of a specific toolchain, we should write portable code
reasonably within a particular standard.

> 2. With the platform requirements above given, C99 and/or C++11 can
> be assumed. Even if we decide not to use any C++ at all, I would
> suggest compile the code with a C++ compiler for reasons of
> portability.

I've seen recommendations to compile C using a C++ compiler. However, if
you refer to Bjarne Stroustrup's authoritative book he admits that
certain incompatibilities exist. C++ is no more standard than C, and C
is just as (maybe even more) portable as C++.

> 3. With defined platform and compilers, cleanup and janitorial work
> can start. This includes, e.g., the use of standard types (like bool
> or uint32_t), standard functions (like calloc), removal of various
> autoconf checks, etc.

I'm in favor of doing this in the mid-term. We already have a nice
collection of compatability macros that can serve as a crutch for
compilers we do not obey C99.

> 4. Modernize architecture and replace existing components.

I'm not exactly sure what this means. I also see no point in replacing
components that have been in service and aren't breaking. I see no harm
in rewriting code, but it'd be a lot more productive to focus on making
the game more fun than fixing what isn't broken.

Thanks,
Kevin Zheng