New Xconq Windows Executable

New Xconq Windows Executable

[Eric McDonald]

Hello all,

  I have just finished building and briefly testing a fresh Xconq 
executable for Windows. It was built and ran on Windows XP; 
hopefully other versions of Windows will not have trouble.

  I have bundled the Cygwin DLL with Xconq. Hopefully this will 
eliminate any need for people to install Cygwin. (*fingers 
crossed*)
  I linked against Tcl/Tk 8.4.4 so that is probably what you will 
want to have installed on your system. I cannot include the 
tcl84 and tk84 DLL's with Xconq due to licensing constraints. You 
can find the DLL's at:
(http://www.activestate.com/Products/Download/Download.plex?id=ActiveTcl). 
Run the installer program that you download. Install Tcl/Tk 
anywhere. Then find tcl84.dll and tk84.dll and copy them into the 
_same_ directory where xconq.exe is located. Then try running 
xconq.exe.
  I will try eliminate the DLL copying step someday when I feel 
more motivated and feel like mucking around in Windows-land again.

  If you have problems (after following the above instructions), 
please let me know what version of Windows you are using, and 
whether you have installed the AS Tcl/Tk package previously, and 
if so, what version. Also please describe the symptoms (error 
messages, etc...).

  The zip file, which includes xconq.exe, the latest games 
library, etc..., is at:
http://eric_mcdonald.home.comcast.net/xconq/xconq20030827.zip

  Enjoy,
    Eric

P.S. By downloading the above zip file, you agree to be a beta 
tester for the new Bellum Aeternum game. :)

Re: New Xconq Windows Executable

[Eric McDonald]

On Tue, 26 Aug 2003, Eric McDonald wrote:

>Then find tcl84.dll and tk84.dll and copy them into the 
> _same_ directory where xconq.exe is located. 

Actually, you can disregard this step unless you are having 
problems getting Xconq to run.

I was thinking about something else when I wrote that.

Re: New Xconq Windows Executable

[Jim Kingdon]

> I cannot include the tcl84 and tk84 DLL's with Xconq due to licensing
> constraints. You can find the DLL's at:
> (http://www.activestate.com/Products/Download/Download.plex?id=ActiveTcl).

Hmm.  Anyone tried the tcl which comes with cygwin (
http://www.cygwin.com/packages/tcltk/ )?

It would presumably be free of said licensing issue, but I don't know
whether it has other issues (for example, maybe it depends on X, which
would probably be more trouble than it is worth).

Re: New Xconq Windows Executable

[Eric McDonald]

Hi Jim,

On Wed, 27 Aug 2003, Jim Kingdon wrote:

> Hmm.  Anyone tried the tcl which comes with cygwin (
> http://www.cygwin.com/packages/tcltk/ )?
> 
> It would presumably be free of said licensing issue, but I don't know
> whether it has other issues (for example, maybe it depends on X, which
> would probably be more trouble than it is worth).

Yes, it does depend on the Cygwin XFree86 X libraries. We would 
then need to have people install the Cygwin XFree86 stuff (which, 
IMO, is much more stable than 2 years ago). And they would 
essentially be playing Unix Xconq in an X display on their Windows 
machine.

As as side note, building Xconq for the AS Tcl/Tk is slightly 
hairier when one has the Cygwin XFree and Tcl/Tk stuff installed 
(as I do). More attention has to be paid to make sure you are 
pointing at the right sets of headers.

As far as the AS licensing is concerned, it looks like all that  
Xconq really needs to do is get written permission to bundle the 
DLL's and Tk Tcl scripts (actually the legalese refers to the 
"Package", which is a superset of what we want/need, I think). AS 
seems to be fairly OpenSource-friendly, so it might be worth a 
shot.

  Regards,
   Eric

Re: New Xconq Windows Executable

[Hans Ronne]

>As far as the AS licensing is concerned, it looks like all that
>Xconq really needs to do is get written permission to bundle the
>DLL's and Tk Tcl scripts (actually the legalese refers to the
>"Package", which is a superset of what we want/need, I think). AS
>seems to be fairly OpenSource-friendly, so it might be worth a
>shot.

This restriction only applies to the package distributed by AS. I think the
main reason is that they want people to always get the latest package from
their web site. The tcl core license goes as follows:

"The authors hereby grant permission to use, copy, modify, distribute, and
license this software and its documentation for any purpose, provided that
existing copyright notices are retained in all copies and that this notice
is included verbatim in any distributions. No written agreement, license,
or royalty fee is required for any of the authorized uses. Modifications to
this software may be copyrighted by their authors and need not follow the
licensing terms described here, provided that the new terms are clearly
indicated on the first page of each file where they apply."

So you are free to distribute tcltk for any purpose. You can also hack the
files and impose your own license variant. This is in effect what AS has
done. However, if you get the sources from sourceforge and build your own
DLLs, or use the binaries at sourceforge (currently available only for the
Mac) there are no restrictions on redistribution. The same applies to the
tcl script files.

Anyway, getting tcltk from AS (for Windows users) is a good idea for
several reasons. First, the AS installer makes sure that all files are put
in the right places. Second, you always get the latest version that way.
Third, tcltk is a huge package, much bigger than Xconq.

Hans

Re: New Xconq Windows Executable

[Eric McDonald]

Hi Hans,

On Wed, 27 Aug 2003, Hans Ronne wrote:

> Anyway, getting tcltk from AS (for Windows users) is a good idea for
> several reasons. First, the AS installer makes sure that all files are put
> in the right places. Second, you always get the latest version that way.
> Third, tcltk is a huge package, much bigger than Xconq.

Not that I care too much about marketing, but I do think that this 
extra step of going out and getting the AS Tcl/Tk reflects poorly 
on Xconq's perceived level of "sophistication."

If we want to release our own Tcl/Tk bundle, I really only think a 
few things would be necessary:
(1) The Tcl and Tk DLL's.
(2) The Tcl scripts for Tk et al.
(3) A .reg file with the appropriate registry entries. (Harcoded 
paths will have to be assumed, I think. Probably something like 
"C:\Program Files\Xconq\ASTcl".)
(4) A simple install.bat to create the official Xconq install 
directory and populate it.

Things could be even smoother and more dynamic if we can find a 
free installer program. I haven't checked the licensing of things 
like InstallShield (Lite?).
But maybe it is not worth the effort....
 
I have not given SDL serious consideration. Are there any 
bundling issues with that?

  Regards,
    Eric

Re: New Xconq Windows Executable

[Hans Ronne]

>If we want to release our own Tcl/Tk bundle, I really only think a
>few things would be necessary:
>(1) The Tcl and Tk DLL's.
>(2) The Tcl scripts for Tk et al.
>(3) A .reg file with the appropriate registry entries. (Harcoded
>paths will have to be assumed, I think. Probably something like
>"C:\Program Files\Xconq\ASTcl".)
>(4) A simple install.bat to create the official Xconq install
>directory and populate it.
>
>Things could be even smoother and more dynamic if we can find a
>free installer program. I haven't checked the licensing of things
>like InstallShield (Lite?).
>But maybe it is not worth the effort....

Well, I would put it like this: why do the job when AS has already done it
for us. Sure, we might be able to prune down tcltk to a lot less than the
80 MB in the AS package, and then bundle it with Xconq. However, consider
what happens if somebody installs a partial tcltk that comes with Xconq and
then finds out he/she needs the full install for some other program. If
there is one thing that can mess upp a system it is installing a full
version of something on top of a partial version or vice versa. I fear that
xconq would be blamed in the end and get a bad rep.

I am not dogmatic about this, however. If it turns out that all you need is
the DLLs and a few script files, it might be worthwhile. We already
included BWidget in Xconq. I haven't checked how many of the tcltk script
files that are really needed to run Xconq. Everything should be installed
in the Xconq directory in that case, in order not to mess up things for
other programs.

>I have not given SDL serious consideration. Are there any
>bundling issues with that?

Not that I am aware of. SDL is under LGPL. In any case, I have been
building the DLLs myself from the SDL sources, since the DLLs from the
official distribution were built with Visual C++ and therefore are
incompatible with apps built by CodeWarrior (which I am using).

Hans

Re: New Xconq Windows Executable

[Juergen Ruehle]

Eric McDonald writes:
 > On Wed, 27 Aug 2003, Jim Kingdon wrote:
 > > Hmm.  Anyone tried the tcl which comes with cygwin (
 > > http://www.cygwin.com/packages/tcltk/ )?
 > > 
 > > It would presumably be free of said licensing issue, but I don't know
 > > whether it has other issues (for example, maybe it depends on X, which
 > > would probably be more trouble than it is worth).
 > 
 > Yes, it does depend on the Cygwin XFree86 X libraries. We would 
 > then need to have people install the Cygwin XFree86 stuff (which, 
 > IMO, is much more stable than 2 years ago). And they would 
 > essentially be playing Unix Xconq in an X display on their Windows 
 > machine.

Actually no: the cygwin tk does not depend on X, but it doesn't
contain the right headers either. You have to download the source to
the tcl/tk package, extract the headers, and configure using

 --x-includes=<<tk's xlib header directory, e.g. /usr/include/tk/xlib>>

(Probably the same you are doing to compile with the AS package).
Otherwise configure will find the standard X11 headers which are
incompatible and the resulting application will crash on startup.

Also it seems there is still some tweaking of at least win/Makefile.in
neccessary. it would be nice if somebody could commit something along
the lines of (one still has to muck with TCLTKLIB, but I see no way to
autodetect this):

===================================================================
RCS file: /cvs/xconq/xconq/win/Makefile.in,v
retrieving revision 1.7
diff -b -B -d -u -I\$$ -r1.7 Makefile.in
--- win/Makefile.in	28 Aug 2003 04:04:00 -0000	1.7
+++ win/Makefile.in	28 Aug 2003 10:55:40 -0000
@@ -56,6 +55,8 @@
 
 TKIAPP_LIB = ../tcltk/libtkiapp.a
 
+MAIN = ../tcltk/tkwin32.o
+
 # Host and target-dependent makefile fragments come in here.
 ####
 # End of host and target-dependent makefile fragments.
@@ -94,20 +95,18 @@
 
 WIN_CFLAGS = -mwindows
 
-ALL_CFLAGS = $(CFLAGS) $(HFLAGS) $(REQD_CFLAGS) $(WIN_CFLAGS) -I$(srcdir) -I$(srcdir)/.. -I$(krnsrcdir) -I$(srcdir)/../tcl/generic -I$(srcdir)/../tk/generic
-
-.c.o:
-	$(CC) -c $(ALL_CFLAGS) $<
-
 # Do it all.
 
 all:	xconq
 
 # The game itself.
 
-xconq: wconq.o $(TKUI_LIB) $(TKIMF_LIB) $(KERNEL_LIB) $(LOW_LIB)
-	rm -f xconq
-	$(CC) -o xconq $(ALL_CFLAGS) $(LDFLAGS) wconq.o $(TKUI_LIB) $(TKIMF_LIB) $(KERNEL_LIB) $(LOW_LIB) $(WITH_LIBS) $(TCLTK_LIB) $(NET_EXTRA_LIBS)
+xconq: $(MAIN) $(TKUI_LIB) $(TKIMF_LIB) $(KERNEL_LIB) $(LOW_LIB)
+	rm -f xconq.exe
+	$(CC) -o xconq $(WIN_CFLAGS) $(LDFLAGS) $(MAIN) $(TKUI_LIB) $(TKIMF_LIB) $(KERNEL_LIB) $(LOW_LIB) $(WITH_LIBS) $(TCLTK_LIB) $(NET_EXTRA_LIBS)
+
+$(MAIN):
+	(cd ../tcltk; make tkwin32.o)
 
 $(KERNEL_LIB):
 	(cd ../kernel; make libconq.a)
@@ -134,7 +133,7 @@
 
 clean:
 	rm -f *.o lint.out core
-	rm -f xconq xconq.6 *.conq *.xconq
+	rm -f xconq.exe xconq.6 *.conq *.xconq
 
 distclean: clean
 	rm -f Makefile config.status
===================================================================


Regards,

	jr

Re: New Xconq Windows Executable

[Eric McDonald]

On Thu, 28 Aug 2003, Juergen Ruehle wrote:

> Eric McDonald writes:

>  > Yes, it does depend on the Cygwin XFree86 X libraries. We would 
>  > then need to have people install the Cygwin XFree86 stuff (which, 
>  > IMO, is much more stable than 2 years ago). And they would 
>  > essentially be playing Unix Xconq in an X display on their Windows 
>  > machine.
> 
> Actually no: the cygwin tk does not depend on X, but it doesn't
> contain the right headers either. You have to download the source to
> the tcl/tk package, extract the headers, and configure using

OK, "depend" was too strong of a word. During my earliest build 
attempt, I was picking up the wrong Tcl/Tk (I forgot that I had 
the Cygwin version of it installed, and its headers were in 
/usr/include which was earlier in the search path than the AS 
headers), and when compiling tkwin32.c, I was getting conflicts 
with what I _assumed_ were the actual X headers that Tcl/Tk 
"depended" on. I'll eat my words for now, until I can verify what 
X headers were actually being used (next time I boot into 
Windows). Sorry for possibly dispensing misinformation based on an 
assumption....

>  --x-includes=<<tk's xlib header directory, e.g. /usr/include/tk/xlib>>
> (Probably the same you are doing to compile with the AS package).

Yes.

> Otherwise configure will find the standard X11 headers which are
> incompatible and the resulting application will crash on startup.

Actually, you probably won't make it past linking, because of the 
overridden definitions at the bottom of tkwin32.c.

> Also it seems there is still some tweaking of at least win/Makefile.in
> neccessary. it would be nice if somebody could commit something along
> the lines of (one still has to muck with TCLTKLIB, but I see no way to
> autodetect this):

I had some similar tweaks in mind, based on my experience with 
that mess. I will look at your patch more closely tonight (US 
Mountain time), unless someone has already committed it by then. 
Thanks.

  Best regards,
    Eric

Re: New Xconq Windows Executable

[Eric McDonald]

On Thu, 28 Aug 2003, Juergen Ruehle wrote:

> Eric McDonald writes:

>  > Yes, it does depend on the Cygwin XFree86 X libraries. We would 
>  > then need to have people install the Cygwin XFree86 stuff (which, 
>  > IMO, is much more stable than 2 years ago). And they would 
>  > essentially be playing Unix Xconq in an X display on their Windows 
>  > machine.
> 
> Actually no: the cygwin tk does not depend on X, but it doesn't
> contain the right headers either. 

Ok, I mounted my NTFS partition that has Cygwin.
I looked at tk.h and it says:
#ifndef _XLIB_H
#   ifdef MAC_TCL
#       include <Xlib.h>
#       include <X.h>
#   else
#       include <X11/Xlib.h>
#   endif
#endif
And the only X11/Xlib.h in my entire Cygwin filespace is under 
/usr/X11R6/include, which, of course, is the real thing, not a 
Tcl/Tk imitation.

So, if anyone was to build a Tcl/Tk-based app under this setup 
(and it is a relatively recent and fairly standard one), he/she 
would, in fact, end up depending on the real X11 stuff. From this 
standpoint, any Cygwin app built thusly would be a true X11 client 
in need of a true X11 server.

But, I suppose this a wasted point, since what you prescribe seems 
like a good idea (it also devalues the AS Tcl/Tk in my eyes). 
It would be nice to build Tcl/Tk for Windows natively under 
Cygwin, and then statically link it into Xconq, removing the 
need of Tcl and Tk DLL's and whatnot. I'll look into it. Thanks.

> Also it seems there is still some tweaking of at least win/Makefile.in
> neccessary. it would be nice if somebody could commit something along
> the lines of (one still has to muck with TCLTKLIB, but I see no way to
> autodetect this):

Your patch looks fine. I was going to commit it later this 
evening, but I suppose I should boot into Windows first and 
actually test it.... I'll take care of it soon, but maybe not 
today.

  Thanks,
    Eric

Re: New Xconq Windows Executable

[Hans Ronne]

>Also it seems there is still some tweaking of at least win/Makefile.in
>neccessary. it would be nice if somebody could commit something along
>the lines of (one still has to muck with TCLTKLIB, but I see no way to
>autodetect this):

This seems OK to me. However, what I really would like to do is to get rid
of the win directory, and make the Windows app build in the tcltk
directory, where the Windows tcltk code now lives. The point of this is an
attempt to organize the sources in a way that makes sense, so that new
users know where to find the files. We also have a Windows SDL app,
furthermore, we have a Mac tcltk app, and the latter does not live in the
mac directory, which instead contains the mac interface.

So the idea was to have all tcltk stuff (sources, resources, Makefiles) in
the tcltk directory, all SDL stuff in the sdl directory etc. One directory
for each interface.

This was discussed on the list earlier, and I already moved the relevant
source and resource files from the win to the tcltk directory. I think
Stanley Sutton started to look at moving the relevant stuff from the win
Makefile.in to the tcltk Makefile.in, but unfortunately he was not able to
complete that work. Perhaps we should do this now?

Hans

Re: New Xconq Windows Executable

[Juergen Ruehle]

Eric McDonald writes:
 > On Thu, 28 Aug 2003, Juergen Ruehle wrote:
 > > Eric McDonald writes:
 > >  > Yes, it does depend on the Cygwin XFree86 X libraries. We would 
 > >  > then need to have people install the Cygwin XFree86 stuff (which, 
 > >  > IMO, is much more stable than 2 years ago). And they would 
 > >  > essentially be playing Unix Xconq in an X display on their Windows 
 > >  > machine.
 > > 
 > > Actually no: the cygwin tk does not depend on X, but it doesn't
 > > contain the right headers either. 

First: sorry for the tone of my mail. I had the suspicion it might
sound patronizing, but English isn't my first language and I had no
better wording available. I very much appreciate the time and effort
you and others (especially Hans) are putting into xconq. I did not
intend to offend anybody.

 > Ok, I mounted my NTFS partition that has Cygwin.
 > I looked at tk.h and it says:
 > #ifndef _XLIB_H
 > #   ifdef MAC_TCL
 > #       include <Xlib.h>
 > #       include <X.h>
 > #   else
 > #       include <X11/Xlib.h>
 > #   endif
 > #endif
 > And the only X11/Xlib.h in my entire Cygwin filespace is under 
 > /usr/X11R6/include, which, of course, is the real thing, not a 
 > Tcl/Tk imitation.
 > 
 > So, if anyone was to build a Tcl/Tk-based app under this setup 
 > (and it is a relatively recent and fairly standard one), he/she 
 > would, in fact, end up depending on the real X11 stuff. From this 
 > standpoint, any Cygwin app built thusly would be a true X11 client 
 > in need of a true X11 server.

Sorry that I worded my explanation poorly. It is slightly more
complicated. You can compile it this way and with some fiddling you
can even link it to the X11 libraries, but it won't run. Tk's internal
structures unfortunately are directly derived from the corresponding
X11 structures. Access to these structures is through macros which are
(mostly) inherited from X and defined in X11/* headers. Now, X based
Tk uses the X structures directly while on Windows (and probably Mac
OS) the layout is slightly different. Linking code with different
opinions on the layout of structures (in this case cygwin tk84.dll
using the windows layout and xconq compiled with X11 headers using the
X11 layout) will result in a segmentation fault rather sooner than
later (I learned this the hard way:-). It would be nice if Win dows Tk
had some deliberate incompatibility with the X11 headers so this could
be detected at compile time.

Langer Rede kurzer Sinn:-)

  When compiling a Tk application for X11 nothing can go wrong, but if
  compiling a Tk app for windows or Mac Tk you have to make sure that
  the compiler doesn't accidently pick up original X11 headers.

 > But, I suppose this a wasted point, since what you prescribe seems 
 > like a good idea (it also devalues the AS Tcl/Tk in my eyes). 
 > It would be nice to build Tcl/Tk for Windows natively under 
 > Cygwin, and then statically link it into Xconq, removing the 
 > need of Tcl and Tk DLL's and whatnot. I'll look into it. Thanks.

There are two alternatives:

 - a cygwin based xconq: and the I think it is The Right Thing(TM) to
   use cygwin Tk in this case (because the installer is already in
   place; actually we could host it using a setup file for the net
   installer)

 - a non-cygwin xconq (either compiled using -mno-cygwin - which I've
   never attempted myself - or using VC++ - which works - or using
   CodeWarrior - which is what Hans is doing AFAIK): this will
   probably have no choice but to use AS Tk

 > > Also it seems there is still some tweaking of at least win/Makefile.in
 > > neccessary. it would be nice if somebody could commit something along
 > > the lines of (one still has to muck with TCLTKLIB, but I see no way to
 > > autodetect this):
 > 
 > Your patch looks fine. I was going to commit it later this 
 > evening, but I suppose I should boot into Windows first and 
 > actually test it.... I'll take care of it soon, but maybe not 
 > today.

It's not really a priority, there are few of us that actually build it
on windows. BTW I think I have posted this earlier, but I'll include
it again: my attempt at an INSTALL-win file. This is probably slightly
outdated by now. It would be nice, if you could review it and perhaps
commit it too. The major part missing is building with Visual C++,
since I currently don't have it installed.

=====================================================
BUILDING XCONQ ON WINDOWS FROM SOURCE

The xconq Tcl/Tk interface should run on most win32 based Systems (95, NT4.0 and
up). Currently (as of 02/08/16) it doesn't build right out of the box but needs
some minor tweaking. The following assumes you have downloaded and extracted the
source on your system and are familiar with building software. Since the windows
port isn't fully maintained, you might have to fix some problems yourself.

If you need further help, please contact the xconq mailing list on
'sources.redhat.com'.

NOTE: This document contains forward slashes as directory separators.

1. Building with cygwin (Net Release)

1.1 Install Cygwin

Install cygwin from http://sources.redhat.com/cygwin/ if you haven't done so
already. You will at least need the 'cygwin', 'ash', 'gcc', 'binutils', and
'make' packages. You also need a Tcl/Tk package as explained in the next
section.

1.2 Install Tcl/Tk Headers and Libraries

IMPORTANT: read this carefully to improve the chance the xconq will actually
build and run.

There are currently three cygwin packages containing Tcl/Tk libraries:

 - 'tcltk' (Version 20001125-1) contains Tcl/Tk Version 8.0
 - 'gdb' (Version 20010428-3) also contains Tcl/Tk Version 8.0
 - 'gdb' (Version 20020718-1) contains Tcl/Tk Version 8.3

If you don't want gdb grab the 'tcltk' package, otherwise install one of the
'gdb' packages.

NOTE: 'gdb' (20010428-3) contains exactly the same Tcl/Tk files as the 'tcltk'
package. So - due to a quirk in the cygwin setup - if you install both and later
deinstall one, it will delete the files, therefore you have to reinstall the
remaining package.

Unfortunately the binary packages do not contain all required header files,
namely Xlib.h and friends. These are only contained in the corresponding source
packages. So download and install (or simply extract it somewhere) the
appropriate source package.

It is important to use the header files that have been used to build the
libraries since crucial functions are implemented as macros. Especially DO NOT
use X11 headers (e.g. from one of the X11 packages). While the compile may
succeed the resulting executable will most probably crash (within expanded macro
code).

That said, it seems that the headers included in the 'tcltk' source package
actually work with all three binary packages (even so the Tcl/Tk versions
differ). This can significantly reduce download time, but YMMV.

1.3 Configure

Make sure that there are no directories named 'tcl' or 'tk' in the xconq source
directory. These are for the old cygwin beta releases. If they exist remove or
rename them. You just need the directory named 'tcltk'.

Start a cygwin shell (e.g. /bin/sh.exe), cd to the directory where you extracted
the source, and type

    ./configure --x-includes=<directory of the modified Tcl/Tk X includes>

This will try to guess the correct settings for your systems, select the Tcl/Tk
X headers, and create Makefiles in the appropriate directories.

The correct X include directory is the one from the Tcl/Tk source containing an
X11 sub directory that contains Xlib.h.

1.4 Make

Run 'make' (in the xconq source directory). Fix any errors that might occur.
This should produce 'win/xconq.exe'.

2. Building xconq using MS Visual C++

2.1 Get and install Tcl/Tk

...

2.2 Setup the project

Create a new project containing the following files:

...

Change the settings as follows:

...

2.3 Compile

Start the compile. Fix any errors that occur.

3. Running xconq

'xconq.exe' should be runnable when copied to the top level xconq source
directory. If it complains that it cannot find 'init.tcl' you have to set the
'TCL_LIBRARY' environment variable to the directory of the 'init.tcl' file (i.e.
'/usr/share/tcl8.0'). If it cannot find other tcl scripts you should try to add
them to the 'TCLLIBPATH' environment variable.

4. Installing xconq

Currently not supported by the build system, but you can copy the executable and
library directories to any directory you like and create a shortcut. You then
probably have to provide the directory of the game library using command line
parameter '-L <game library directory>'and possibly set TCLLIBPATH to the
directory of the 'tkconq.tcl' script.
=====================================================

Re: New Xconq Windows Executable

[Eric McDonald]

On Fri, 29 Aug 2003, Hans Ronne wrote:

> This was discussed on the list earlier, and I already moved the relevant
> source and resource files from the win to the tcltk directory. I think
> Stanley Sutton started to look at moving the relevant stuff from the win
> Makefile.in to the tcltk Makefile.in, but unfortunately he was not able to
> complete that work. Perhaps we should do this now?

Doesn't seem too difficult. I will attempt to take care of it 
tonight, and modify/crossover/integrate Juergen's patch 
accordingly.

Re: New Xconq Windows Executable

[Eric McDonald]

On Fri, 29 Aug 2003, Juergen Ruehle wrote:

> intend to offend anybody.

No offense taken. If I am wrong about something, then I want to 
know.

> Sorry that I worded my explanation poorly. It is slightly more
> complicated. You can compile it this way and with some fiddling you
> can even link it to the X11 libraries, but it won't run. Tk's internal
> structures unfortunately are directly derived from the corresponding
> X11 structures. Access to these structures is through macros which are
> (mostly) inherited from X and defined in X11/* headers.

Yes, I know. When I was developing the BadDrawable fix a couple 
months ago (my first serious experience with Tcl/Tk) I saw that, 
in a number of cases, there was essentially a 1:1 correspondance 
between the Tk function and the X11 function.

> Tk uses the X structures directly while on Windows (and probably Mac
> OS) the layout is slightly different.

Obviously. On Windows, Tcl/Tk must at some level map its calls to 
GDI/DirectDraw calls. And on the Mac, it must map to QuickDraw (if 
Apple still calls it that; I have not programmed for the Mac in a 
long time). Naturally, there will be different underlying 
structures as well, since we are talking about different API's.

> opinions on the layout of structures (in this case cygwin tk84.dll
> using the windows layout and xconq compiled with X11 headers using the
> X11 layout) will result in a segmentation fault rather sooner than
> later 

Not surprising. I was not advocating this approach, btw.
I was suggesting that if one built it with the real X11 headers 
(and libraries) then one should be running it on the Cygwin 
XFree86 server (which is quite stable these days, IMO). However, 
we obviously should not be asking Xconq Windows users to do this.

After you mentioned (or I thought you mentioned) that the full 
Tcl/Tk source (not the AS flavor) could be built under Cygwin and 
that it could use the special Tcl/Tk X headers for Windows, __then 
I stated that I liked that approach better than the existing one 
of using the AS stuff.

> had some deliberate incompatibility with the X11 headers so this could
> be detected at compile time.

I thought the 3 dummy X functions at the end of tkwin32.c were a 
result of this incompatibility.

> Langer Rede kurzer Sinn:-)

I don't know any Deutsch, unless the words are cognate with 
the Anglo-Saxon inheritance of English. If it is a famous saying, 
please pardon my ignorance.

>  - a cygwin based xconq: and the I think it is The Right Thing(TM) to
>    use cygwin Tk in this case (because the installer is already in
>    place; actually we could host it using a setup file for the net
>    installer)

I agree. I am going to try this approach. With one twist: I will 
try to statically link the Cygwin Tcl/Tk stuff into Xconq, and 
include the necessary Tcl scripts as part of the end product. This 
will remove the need (if it works) of the end user needing to get 
the Cygwin Tk (which is even worse than having him/her get the AS 
stuff, IMO).

> outdated by now. It would be nice, if you could review it and perhaps
> commit it too.

OK, I will look it over. I may need to modify it to account for 
the fact that the win stuff is getting transplanted to the tcltk 
and sdl directories.

  Thanks,
   Eric

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

[Eric McDonald]

On Fri, 29 Aug 2003, Hans Ronne wrote:

> attempt to organize the sources in a way that makes sense, so that new
> users know where to find the files. We also have a Windows SDL app,
> furthermore, we have a Mac tcltk app, and the latter does not live in the
> mac directory, which instead contains the mac interface.

However, there does not appear to be any make target for the Mac 
Tcl/Tk interface in the tcltk Makefile (which might be useful 
for building on Mac OS X with GNU tools). Do you supply your own 
CW or MPW project when you build this interface?
 
> So the idea was to have all tcltk stuff (sources, resources, Makefiles) in
> the tcltk directory, all SDL stuff in the sdl directory etc. One directory
> for each interface.

Pieces of the X11 Tcl/Tk app are actually built in the x11 
directory rather than the tcltk directory. If we really want to 
be consistent, then we would also need to move the X11 Tcl/Tk 
stuff into the tcltk directory, not just the Win32 Tcl/Tk stuff.

For the time being I am just going to apply Juergen's patch. 
(Nearly a week after I said I would. ;-)

  Regards,
   Eric

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

[Hans Ronne]

>Pieces of the X11 Tcl/Tk app are actually built in the x11
>directory rather than the tcltk directory. If we really want to
>be consistent, then we would also need to move the X11 Tcl/Tk
>stuff into the tcltk directory, not just the Win32 Tcl/Tk stuff.

That's right. The tcltk app (xconq) is built in the x11 directory for
purely historical reasons, as well as the sdl app (sdlconq). However,
neither of these apps use any of the x11 code. Nor does the x11 app
(xtconq) use the single source file shared by xconq and sdlconq (xconq.c,
which contains the main function) since it has its own main function in
xtconq.c. So the code is already completely separated between the x11 and
tcltk/sdl interfaces. What remains to do is to untangle it further by
giving each of the latter its own main function file which lives in the
tcltk or sdl directory, respectively, instead of in the x11 directory.

I would suggest doing this in two steps. First, we should copy xconq.c to
the tcltk directory (and rename it to tkunix.c if we want to be really
consistent with how the tcltk mac and win32 source files are named). After
this, it is easy to rearrange the Makefiles so that we have a single
Makefile for the tcltk apps in the tcltk directory. The sdl-specific hacks
such as using_sdl can of course be removed from tkunix.c at this point.

A second step would be to do exactly the same thing with the sdl code, i.e.
copy xconq.c to a new file sdlunix.c in the sdl directory and change the
Makefiles so that sdlconq builds there instead of in the x11 directory.
Once this has been done, the old x11/xconq.c can be retired.

We also have the tcltk app ximfapp. It's main function file, ximfapp.c is
not used by the sdl interface (or by the x11 interface) so in this case we
can just move it to the tcltk directory (and rename it iappunix.c for
consistency). The Makefiles would of course have to be updated, too. The
other utility programs are all true x11 apps and should be left to build in
the x11 directory together with xtconq.

The advantage of these rearrangements are two-fold. First, it will be
easier keep track of what files belong to what interfaces. Second, one
would no longer need hacks supporting several different interfaces within
the same source file, as is now the case for xconq.c. The only disadvantage
is the slight code duplication. However, I think we can live with this. The
entire xconq.c is only 241 lines including the comments.

Hans

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

[Eric McDonald]

Hi Hans, Juergen,

  Juergen, I applied your patch and everything seemed fine (as 
expected). I haven't committed the changes yet because I am 
experimenting with building a completely statically-linked Xconq 
app. I built the Sourceforge distro of Tcl/Tk under Windows (had 
to use the MinGW compiler though), and am linking against that.

On Fri, 5 Sep 2003, Hans Ronne wrote:

> The advantage of these rearrangements are two-fold. First, it will be
> easier keep track of what files belong to what interfaces. Second, one
> would no longer need hacks supporting several different interfaces within
> the same source file, as is now the case for xconq.c. The only disadvantage
> is the slight code duplication. However, I think we can live with this. The
> entire xconq.c is only 241 lines including the comments.

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.

  Thanks,
    Eric

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

[Hans Ronne]

>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

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

[Eric McDonald]

On Fri, 29 Aug 2003, Hans Ronne wrote:

> This seems OK to me. However, what I really would like to do is to get rid
> of the win directory, and make the Windows app build in the tcltk
> directory, where the Windows tcltk code now lives. The point of this is an

Done.

> users know where to find the files. We also have a Windows SDL app,

I will get to the Windows SDL app in the next few days 
(hopefully). For the time being, building it may require some 
"manual intervention".

Eric

P.S. I also checked that Cconq still built so that I wouldn't get 
any curses hurled my way. :-)

Re: Tcl/Tk Interface Unification

[Eric McDonald]

Hi Hans, others,

On Fri, 5 Sep 2003, Hans Ronne wrote:

> tcltk/sdl interfaces. What remains to do is to untangle it further by
> giving each of the latter its own main function file which lives in the
> tcltk or sdl directory, respectively, instead of in the x11 directory.

This I have now done for both the Tcl/Tk and SDL interfaces. 
However, I still need to go into the files and clean out all of 
the residual stuff.

> Once this has been done, the old x11/xconq.c can be retired.

I have not stowed anything in the Attic yet.

> easier keep track of what files belong to what interfaces. Second, one
> would no longer need hacks supporting several different interfaces within
> the same source file, as is now the case for xconq.c. The only disadvantage

Now we just have makefile hacks to determine which interface to 
build when someone does "make all-xconq". And more makefile hacks 
to determine which compile and link flags to use depending on the 
build platform....

Some of these things can be simplified by making the configure 
script do more host-dependent configuration of certain make 
variables. Another thing that I think would help would be to add 
a new config flag, "enable-ui". This would take one of the 
following arguments: tcltk, sdl, xtxaw, curses. And "tcltk" would 
be the default setting, at least while the SDL interface is so 
primitve. This would also deprecate the usage of "enable-sdl".

Basically, I think there is a lot of polish that needs to be 
applied to the configury and build system.

  Regards,
    Eric 

Re: Tcl/Tk Interface Unification

[Hans Ronne]

>> tcltk/sdl interfaces. What remains to do is to untangle it further by
>> giving each of the latter its own main function file which lives in the
>> tcltk or sdl directory, respectively, instead of in the x11 directory.
>
>This I have now done for both the Tcl/Tk and SDL interfaces.
>However, I still need to go into the files and clean out all of
>the residual stuff.
>
>> Once this has been done, the old x11/xconq.c can be retired.

Great job! I think this will save us some gray hairs in the future.

>Now we just have makefile hacks to determine which interface to
>build when someone does "make all-xconq". And more makefile hacks
>to determine which compile and link flags to use depending on the
>build platform....
>
>Some of these things can be simplified by making the configure
>script do more host-dependent configuration of certain make
>variables. Another thing that I think would help would be to add
>a new config flag, "enable-ui". This would take one of the
>following arguments: tcltk, sdl, xtxaw, curses. And "tcltk" would
>be the default setting, at least while the SDL interface is so
>primitve. This would also deprecate the usage of "enable-sdl".

Right. But wouldn't it be simpler to just scrap enable-sdl and enable
building by default of all interfaces that are supported in terms of
installed libraries? This is after all how cconq already works. As long as
all apps have different names, there should be no problems.

If it is easy to build all apps (meaning that no extra configurations are
needed), more users will do that, which will provide us with more user
feedback. Otherwise, the only people who are ever going to build the
non-tcltk apps are those who are hacking them.

>Basically, I think there is a lot of polish that needs to be
>applied to the configury and build system.

Yes. Another inconsistency right now is where the apps are built. Cconq is
built in the curses directory, which makes sense, but xconq and sdlconq are
built in the x11 directory, which doesn't make much sense anymore. One
solution would be to build them in the tcltk and sdl directories,
respectively. Another is to put all apps in the top directory, as is
already done for the Mac and Windows apps. I think the latter option has
some advantages, since it makes it easier to find the apps for the
inexperienced user. The top directory is also the only location where the
apps work consistently on all platforms.

Hans

Re: Tcl/Tk Interface Unification

[Eric McDonald]

On Mon, 15 Sep 2003, Hans Ronne wrote:

> >following arguments: tcltk, sdl, xtxaw, curses. And "tcltk" would
> >be the default setting, at least while the SDL interface is so
> >primitve. This would also deprecate the usage of "enable-sdl".
> 
> Right. But wouldn't it be simpler to just scrap enable-sdl and enable
> building by default of all interfaces that are supported in terms of
> installed libraries? This is after all how cconq already works. As long as
> all apps have different names, there should be no problems.

We can do that. But this would mean that someone would still have 
to explicitly do:
  make all-cconq
  make install-cconq
to get the curses interface. I think this requires the same amount 
of knowledge as knowing to add a configure option on the command 
line. And "configure --help" gives better feedback to a user than 
reading a Makefile template to find out what interfaces are 
available.

I was thinking that with the enable-ui option we could then just 
choose an interface at configure time, and then, if 
enable-ui=curses:
  make
  make install
would simply do the trick.

Of course, the main motivator is that I could easily include a 
dir=@UI_DIR@ in all of the top-level targets, and this would make 
things a bit nicer than the SDL_LIB test that I have now.

> Yes. Another inconsistency right now is where the apps are built. Cconq is
> built in the curses directory, which makes sense, but xconq and sdlconq are
> built in the x11 directory, which doesn't make much sense anymore.

The changes, which I announced earlier, address this. (They are 
the reason why I haven't committed anything for nearly a week. :-)

> One
> solution would be to build them in the tcltk and sdl directories,
> respectively. 

This is the solution I implemented.

>Another is to put all apps in the top directory, as is
> already done for the Mac and Windows apps. I think the latter option has
> some advantages, since it makes it easier to find the apps for the
> inexperienced user. The top directory is also the only location where the
> apps work consistently on all platforms.

IMO, the top-level Makefile would be greatly cluttered if we built 
the apps there. But, I agree, the executables would be easier to 
find if they were placed there. I will make it so executables 
(xconq,cconq,wconq.exe) get copied upstairs from their build 
directories. 

  Regards,
   Eric

Re: Tcl/Tk Interface Unification

[Hans Ronne]

>I was thinking that with the enable-ui option we could then just
>choose an interface at configure time, and then, if
>enable-ui=curses:
>  make
>  make install
>would simply do the trick.

I see your point. I think we can have the best of both ways. First, we add
a configure option to make something else than xconq (tcltk) the default
target, as you suggest. Second, we enable building of all targets by name,
provided that the correct libraries are installed. That way, "make" would
build xconq (tcltk) and "make all-sdlconq" (or perhaps just "make sdlconq")
would build sdlconq without any extra configurations. It was the need to
add --enable-sdl every time you run ./configure that I wanted to get rid
of. I don't know how many times I forgot to do that and ended up not being
able to build sdlconq.

>IMO, the top-level Makefile would be greatly cluttered if we built
>the apps there. But, I agree, the executables would be easier to
>find if they were placed there. I will make it so executables
>(xconq,cconq,wconq.exe) get copied upstairs from their build
>directories.

An excellent idea.

Hans

Re: Tcl/Tk Interface Unification

[Eric McDonald]

On Mon, 15 Sep 2003, Hans Ronne wrote:

> I see your point. I think we can have the best of both ways.

Agreed. I guess I wasn't clear. I definitely would not rip out the 
existing targets for specific interfaces in the top-level 
Makefile.

I envision something like

  UI_TARGET = @UI_TARGET@

  all: $(UI_TARGET)

  tkconq:
    ...
  
  xtconq:
    ...

  sdlconq:
    ...

  cconq:
    ...

>Second, we enable building of all targets by name,

This is essentially done, except for sdlconq (as you noted), and 
perhaps the tcltk target should be tkconq rather than all-xconq 
and all-wconq, since we are trying to remove the notion of 
platform from the build process.

And this brings up another issue: what should executables be 
named? Currently, things are set up so that both the X11 SDL and 
Tcl/Tk executables get named xconq, and the Windows SDL and Tcl/Tk 
executables get named wconq.exe. In retrospect, perhaps I should 
have set them up to be named sdlconq[.exe] and tkconq[.exe] 
without regard to platform. This would be more in line with cconq. 
What do you think?

> would build sdlconq without any extra configurations. It was the need to
> add --enable-sdl every time you run ./configure that I wanted to get rid
> of. I don't know how many times I forgot to do that and ended up not being
> able to build sdlconq.

I've done it a few times myself. I also want to see the need for 
enable-sdl go away. That is part of the configury "polish" I was 
referring to. I will work on this as part of my next pass through 
the configuration/build system, now that the major surgery has 
been done.

  Thanks,
   Eric

Re: Tcl/Tk Interface Unification

[Hans Ronne]

>This is essentially done, except for sdlconq (as you noted), and
>perhaps the tcltk target should be tkconq rather than all-xconq
>and all-wconq, since we are trying to remove the notion of
>platform from the build process.

That would make sense.

>And this brings up another issue: what should executables be
>named? Currently, things are set up so that both the X11 SDL and
>Tcl/Tk executables get named xconq, and the Windows SDL and Tcl/Tk
>executables get named wconq.exe. In retrospect, perhaps I should
>have set them up to be named sdlconq[.exe] and tkconq[.exe]
>without regard to platform. This would be more in line with cconq.
>What do you think?

Since the name of the game is "xconq" and nothing else, it makes sense to
call the app xconq whenever possible without confusion. This is also how
Stan set up things originally. For example, the Mac app was simply named
Xconq just like the Unix app.

The best solution when multiple targets are around is probably to name the
default build target "Xconq[.exe]" and to keep the other names
(cconq[.exe], tkconq[.exe], sdlconq[.exe] and xtconq) for targets built by
name.

I agree that we can do without "wconq". Otherwise, we should rename the Mac
app "mconq" for consistency. But there is no reason to do that. I always
considered the name "wconq" a temporary hack. Xconq.exe is better.

BTW, the same logic should apply to the image app. It is now named "imfapp"
on the Mac, "wimfapp.exe" on Windows and "ximfapp" on Unix. Why not just
call it "imfapp[.exe]" everywhere? (by strict analogy to xconq it should
perhaps really be named "ximfapp" but the name "imfapp" is what has been
used mostly, even when referring to the unix app).

Hans

Build system overhaul (Was: Tcl/Tk Interface Unification)

[Juergen Ruehle]

Please note that at least on cygwin the sdl build can't share the same
library objects (e.g. kernel) with the other interfaces because it
require different compiler options (i.e. -mno-cygwin) which result in
different (and incompatible) sets of header files and libraries being
used.

This could be worked around by creating non cygwin versions of the
tcl/tk, curses, and x11 interfaces which is not easy, because the
-mno-cygwin libc provides significantly less functionality which is no
problem for xconq itself but definitely a problem for building the non
cygwin versions of curses and the X11 libraries (for tcl/tk we can use
the active state version?).

A general solution would therefore require providing a separate build
directory for some interfaces (and consequently compiling the kernel
more than once).

    jr

Re: Build system overhaul (Was: Tcl/Tk Interface Unification)

[Eric McDonald]

Hello Juergen et al.,

On Tue, 16 Sep 2003, Juergen Ruehle wrote:

> Please note that at least on cygwin the sdl build can't share the same
> library objects (e.g. kernel) with the other interfaces because it
> require different compiler options (i.e. -mno-cygwin) which result in
> different (and incompatible) sets of header files and libraries being
> used.

Yes, I noticed this. I am still sorting through how to best deal 
with it. Adding the `sdl-config --static-libs` stuff to the 
linker arguments in the SDL dir was only part of the fix, and 
even that may still need some filtering. However, I think this 
must be expanded to the kernel dir as well, and that in the case 
of the SDL interface, HFLAGS = -mwin32 is not appropriate.

I will get back to this problem after I finish my current pass 
through the build system.

> This could be worked around by creating non cygwin versions of the
> tcl/tk, curses, and x11 interfaces which is not easy, because the
> -mno-cygwin libc provides significantly less functionality which is no
> problem for xconq itself but definitely a problem for building the non
> cygwin versions of curses and the X11 libraries (for tcl/tk we can use
> the active state version?).

Or one could just have each interface do a "make 
clean" on the kernel dir, and then pass/override the 
appropriate make flags when making libconq.a and libconqlow.a. 

> A general solution would therefore require providing a separate build
> directory for some interfaces (and consequently compiling the kernel
> more than once).

I think we both might be suggesting the same thing. You are 
welcome to submit a patch if you would like to see this fixed 
sooner rather than later. (Please note that you may want to change 
some of the places where I use $(krnsrcdir) to a $(krnblddir) or 
something along those lines.)

Eric

Re: Build system overhaul (Was: Tcl/Tk Interface Unification)

[Eric McDonald]

Hi again,

On Tue, 16 Sep 2003, Juergen Ruehle wrote:

> A general solution would therefore require providing a separate build
> directory for some interfaces (and consequently compiling the kernel
> more than once).

On second thought, how about we just make libconq_mw32.a and 
libconqlow_mw32.a for anything that is doing a mingw32 build and 
make the regular kernel libs (once, not multiple times) for 
anything that is doing a cygwin or other build?

This would save us the hassle of separate build dirs or remaking 
the kernel multiple times. And since we are using special flags 
with the mingw32 builds anyway, it should be trivial to make 
us link against the alternate libraries as well.

  Regards,
   Eric

Re: Build system overhaul (Was: Tcl/Tk Interface Unification)

[Hans Ronne]

>On second thought, how about we just make libconq_mw32.a and
>libconqlow_mw32.a for anything that is doing a mingw32 build and
>make the regular kernel libs (once, not multiple times) for
>anything that is doing a cygwin or other build?
>
>This would save us the hassle of separate build dirs or remaking
>the kernel multiple times. And since we are using special flags
>with the mingw32 builds anyway, it should be trivial to make
>us link against the alternate libraries as well.

I was just about to suggest that. If we need different variants of the
libraries, we could still build them in the same directory provided that we
give them different names.

Hans

Re: Build system overhaul (Was: Tcl/Tk Interface Unification)

[Juergen Ruehle]

Hello Eric,
 > > A general solution would therefore require providing a separate build
 > > directory for some interfaces (and consequently compiling the kernel
 > > more than once).
 > 
 > On second thought, how about we just make libconq_mw32.a and 
 > libconqlow_mw32.a for anything that is doing a mingw32 build and 
 > make the regular kernel libs (once, not multiple times) for 
 > anything that is doing a cygwin or other build?
 > 
 > This would save us the hassle of separate build dirs or remaking 
 > the kernel multiple times. And since we are using special flags 
 > with the mingw32 builds anyway, it should be trivial to make 
 > us link against the alternate libraries as well.

Would we have separate targets for these in kernel/Makefile or do we
completely parameterize the build and pass in the flags and the target
names from the calling Makefile? Are there more options?

I like the second approach better, because it keeps all the special
flags in one place (i.e. in sdl/Makefile which started this discussion
in the first place) and (unlikely) future occurences of this problem
would not require changes to kernel/Makefile.in, but the first
solution seems much simpler to implement. But obviously it's up to
whoever implements this (which probably wont be me:-)

Happy hacking,
      jr

Re: Build system overhaul

[Eric McDonald]

Guten tag Juergen,

On Wed, 17 Sep 2003, Juergen Ruehle wrote:

> Would we have separate targets for these in kernel/Makefile or do we
> completely parameterize the build and pass in the flags and the target
> names from the calling Makefile? Are there more options?

I have not thoroughly investigated the matter, but I am thinking 
about making separate targets so that we can take advantage of 
make's ability to see if a target is "up to date". Otherwise, we 
must include a "[ -f libconq_mw32.a ]" test in the target commands 
or be forced to rebuild the lib every time the target gets 
invoked. But, I also think it would be wise to supply the make 
flags from the invoking makefile (i.e., the one in the sdl dir) 
even in the case of separate targets. This would reduce the 
number of alternate flag configurations that would have to be 
maintained in various makefiles.

> solution seems much simpler to implement. But obviously it's up to
> whoever implements this (which probably wont be me:-)

In that case, it will probably be me. ;-)

  Regards,
    Eric