Complete.Org: Mailing Lists: Archives: freeciv-dev: November 1999:
[Freeciv-Dev] Anyone else working on multiple-client support?
Home

[Freeciv-Dev] Anyone else working on multiple-client support?

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: freeciv-dev@xxxxxxxxxxx
Subject: [Freeciv-Dev] Anyone else working on multiple-client support?
From: "jrb3@xxxxxxxx (Joseph Beckenbach III, CCP)" <jrb3@xxxxxxxx>
Date: Wed, 24 Nov 1999 10:47:29 -0800
Reply-to: jrb3@xxxxxxxxx

Hi folks!

        In order to really get cranking on the port of Freeciv to the BeOS,
I'm going to need to do some major surgery to the client build support.
Please let me know if someone's already working on this, or if you have some
comments/feedback to help make it slip in more easily.


        Top-level configure.in will require rewriting the client-selection
logic to support more than "XAW" and "everthing else is GTK".  The enable
option for client will honor "no" (--disable-client), "xaw", "gtk", "beos",
"stub", "yes", and anything else of interest (maybe "win32", "mac", "amiga"?).

        client=no means not to attempt compilation.  client=yes will attempt
to guess, starting with the platform-independent clients and walking through
the platform-specific clients;  if the entire list is walked and nothing fits,
error out.  (This will allow attempts to compile GTK client on the BeOS, once
GTK is stable enough.)  If a client is requested, but not supported, it will
revert to guessing.  If there's no client/gui-$client/ directory, configure
will likewise revert to guessing.


        Each client will have a client/gui-$client/ directory.  The makefiles
under client/ (and the configure.in stuff they require) will be reworked to
handle these cleanly.

        The "stub" client will be a trivial textual client which satisfies all
linkage requirements, prints "FreeCiv rules!" to stdout, and exits cleanly.
This provides a known stable point of departure for porting new clients.

        The "beos" client will require that guarded 'extern "C"' statements be
scattered judiciously around in the common headers -- the BeOS API for GUI work
is pure C++.  Not surprisingly, the top-level configure.in will need a little
tweaking (as will top-level aclocal.m4, working around a BeOS autoconf bug).
The draft "beos" client will simply be a copy of "stub" which runs cleanly
after being built by the C++ compiler.


        Once all this is in place, then I can start the BeOS port in earnest.
I think I've done all the other exploratory work I need ....

                Joseph

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