[crossfire] Crossfire server code cleanup/janitorial

[Tolga Dalman]

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.

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.

I have no intent to start a flame war about anything or breaking functionality.
Instead, I'd like you to consider my proposal consisting of these steps:

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.

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.

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.

4. Modernize architecture and replace existing components.

Best regards
Tolga Dalman



On 04/21/2014 08:23 AM, Mark Wedel wrote:
>
>   Going back to to the original thread - certainly win32 is used, and I also do
> sun/solaris.
>
>   I'm not sure if there is any conditional code based on platforms in crossfire
> - if there is, I would think most could be removed through proper configure
> checks (that code may predate the conversion to autoconf).  I suspect in the
> case of sgi/irix, vax/ultrix and perhaps a few others, if support disappeared,
> no one would care.  But without knowing specific areas, support for those might
> also be part of support for other platforms (something like a #if defined(irix)
> || defined(sun) ) or the like, so just removing irix doesn't do much.
>
>   I think some of that might be sound code for the client - though even on
> linux, it seems that the sound 'standard' changes every 5 years or so.
>
> Changing C standard is certainly something worth discussing - C99 would be
> reasonable (in my mind) - C11 may be a bit too recent - while it may be widely
> supported, it might also mean that certain users would be forced to upgrade
> their compilers (and perhaps other parts of their system) faster than they
> really want.  But it also really comes down to features - What C11 (or even C99)
> features are out there that would be of benefit to crossfire?  I'm not familiar
> enough with the different standards to make any assessment on that.
>
> C++ has been touched on some.  I'd add that there are going to be more C
> programmers than C++ programmers, just on the basis that to know C++, you need
> to know C.  So by switching to C++, you may very lose some number of current or
> future potential developers.
>
> I'm also suspect that doing a piecemeal conversion wouldn't be at all useful -
> while there is lots of crufty code in crossfire, you'd really want to look and
> figure out how all the classes interact and so forth.  Otherwise, you may just
> end up with a C++ version of crossfire which is fundamentally the same, just
> written in C++.
>
>   I'm always a bit concerned about rewriting stuff just for the sake of
> rewriting - while it may find (and fix) some existing bugs in the code, almost
> certainly more new bugs will be introduced.
>
>   So echoing some previous comments, I think gameplay should drive more new
> features.  I also think it would be helpful to express what the benefits of the
> changes are.
>
> In terms of roadmap, I think there were some out on the wiki.  But like most
> volunteer based projects, trying to stick to any such roadmap gets difficult -
> people tend to work on what they want to work on, and it may or may not match
> something on the roadmap.
>
>
>
> _______________________________________________
> crossfire mailing list
> crossfire at metalforge.org
> http://mailman.metalforge.org/mailman/listinfo/crossfire