Re: Tcl/Tk Interface Unification (was Re: New Xconq WindowsExecutable)

[Hans Ronne <hronne at telia dot com>]

>I am not particularly keen on the idea of maintaining two separate
>sources that are partially duplicate. Perhaps we can could do
>something like:
>  #include "x11/xconq-common.c"
>or
>  #include "platform/unix/xconq-common.c"
>in both tkunix.c and sdlunix.c ...? Even though we would possibly
>be including function definitions in multiple places, we would not
>run into link-time troubles, because only one of the interfaces is
>being built.

It could certainly work, but I don't think this code duplication is a big
deal. We are basically talking only about the main function. I don't think
the other stuff has to be in there. The default_player functions should
probably be moved to the common code, perhaps with an ifdef UNIX (dummy
functions are used on both Windows and MacOS). And the x signal error
handling functions that make up the rest of xconq.c is just garbage left
from the x11 interface. The xconq.c main does not call
init_x_signal_handlers, unlike the xtconq.c (=old xconq.c) main.

You could further argue that the code duplication already took place when
the x11 interface and tlctk/sdl interfaces got their own partially
duplicate main files (xtconq.c and xconq.c respectively). The only question
now is if we should be consistent and let the tcltk and sdl interfaces each
has its own main, which also lives in the right directory (and not in x11
where neither of them belongs).

Apart from the general neatness of having each interface live in its own
directory, we could then do away with ugly hacks such as using_sdl, a
global that has to be defined as false for the tcltk interface in order to
inform the shared main that we are not using the sdl interface. Seems to me
that when you need hacks like this to use one function for two interfaces,
the time for a code split has come.

Hans