Re: Standardizing the Windows build

[Hans Ronne <hronne at comhem dot se>]

>>From private discussion with Eric, it seems there is no standard,
>canonical build environment for Xconq on Windows.  There aren't even any
>regular Windows developers, apparently?  Xconq development is
>Linux-centric and that does not result in reliable build procedures
>under Windows.  This is an impediment to Windows developers, such as
>myself, contributing anything to Xconq.

As somebody who uses Mac OS 90% of the time, I wouldn't quite agree that
Xconq-development is Linux-centric :-). In fact, the Tcl interface was
largely modelled on the Mac interface, which was the first "modern" Xconq
(not counting the old X11 interface). But I get your point. The Windows
version started with Cygwin, for various reasons. Stan worked at Cygnus
when he wrote most of Xconq.

>- Weaning Xconq of Unix-specific Cygwin code.  I realize that Cygwin is
>needed because Xconq is fundamentally a Unix app.  But I'd like to see
>the Unix-specific stuff isolated as much as possible.  Cygwin
>compilation perhaps becomes a custom build step in an otherwise MS
>Visual Studio build.

Cygwin is in not needed for Xconq any more than the Mac interface is. The
kernel is completely platform and interface independent. The only reason
for supporting Cygwin is that some Xconq developers like it a lot. I
suggested that we should drop Cygwin support two years ago, when we first
got it to build natively under Windows. That was not a popular idea on this
list, however.

The Xconq philosophy is to keep support for diverse platforms and build
tools as long as it does not get in the way of things. People who have a
specific interest usually add and maintain support. Example: the MinGW
support was added by Juergen Ruehle. Eric has worked a lot with the Cygwin
support recently.

When something is not used and gets in the way, we are not sentimental
about keeping it. The Mac interface used to build with Apple's MPW, Think C
and CodeWarrior. We threw out MPW and Think C last year since few use them
anymore.

>Ok, before anyone even wastes time arguing about *those* issues, I think
>I'd better give you full disclosure on my various development agendas.

>First disclosure: I won't write C code [...] You can think of me as a
>Python guy who's
>begrudgingly doing C# so he can get gigs in Redmond.

>Second disclosure: I'm interested in DirectX and .NET stuff.  Sure it's
>not portable.  But, if a platform specific set of code is kept small, I
>don't care.  I'm not interested in religion about how you've gotta use
>portable everywhere for everything.

>Third disclosure: as a game designer, I'm not interested in
>conservatively tweaking and refining Xconq.  I'm interested in building
>new games with Xconq code.  I don't really have a handle on your
>developer culture in this regard yet... it seems you guys create some
>very different things with this GDL layer of yours.

>So, that's who I am.  Friend or foe?

Anybody who wants to contribute to Xconq is a friend. I don't see any major
problems with your agenda unless you wish to impose platform and/or
interface-dependent solutions that would create problems for the other
platforms and interfaces. But I think that can be avoided, because of the
platform and interface-independent nature of the Xconq kernel. What this
means is that if you want to add specific improvements to the Windows
interface, such as DirectX support, or even write a completely new Windows
interface, this is possible without messing up the Mac or Unix interfaces.

OTOH, if you want to hack the kernel, you do have to worry about
maintaining support for the other interfaces. Since you said you "won't
write C code" your contributions to the kernel would, however, be rather
limited, at least as things stand right now.

Actually, there are three very different aspects of Xconq development:
writing new games, improving the interfaces and hacking the kernel.

Most contributors to Xconq have started in either of two ways, by writing
new games or by improving their favourite interface. I gather you are
interested in both. You want to add DirectX support to the Windows
interface(s). But you also say you are interested in building new games.
Fine. What you should realize, however, is that if you are serious about
building new games (and not just modding existing ones) this will very
quickly bring you into the kernel. Every game I have written eventually led
me into the kernel, either to add new ideas or improve GDL support for
existing ones.

And the kernel is of course written in C. If you want to write entirely new
games you would therefore in the end have to get your hands dirty with C.
Either that or rewrite the kernel in your favourite language (Python?). If
you want to give it a try, you are welcome to do so, but be warned: others
have tried before. The most serious attempt so far was made by Ed
Oskiewicz. He made sure Xconq would build under C++ (and still maintain
compatibility with plain C). However, it is a big leap from there to
actually transform the kernel into object oriented code. And it is a leap
that cannot be taken in small steps.

So my guess is that you would find it easier to work on the Windows
interface, given your stated interests and preferences. A Windows-native
(non-Tcl) interface would be a very welcome contribution to Xconq. Tcl has
severe limitations, which you can easily see if you compare the Mac TCL and
Mac PPC native interfaces of Xconq.

One thing that I strongly believe in when it comes to interface
improvements is SDL. Stan started to work on an SDL interface three years
ago, and it builds on all three platforms. It is much faster than TCL and
also much easier to code (it took me just one day to get the Mac version of
Xconq for SDL up and running). This, and the extensive cross-platform
support makes it an attractive alternative as a future Xconq interface. But
SDL is of course written in plain C ...

Hans