* New Xconq Windows Executable @ 2003-08-27 4:29 Eric McDonald 2003-08-27 16:17 ` Eric McDonald 2003-08-27 16:37 ` Jim Kingdon 0 siblings, 2 replies; 32+ messages in thread From: Eric McDonald @ 2003-08-27 4:29 UTC (permalink / raw) To: xconq7 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. :) ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: New Xconq Windows Executable 2003-08-27 4:29 New Xconq Windows Executable Eric McDonald @ 2003-08-27 16:17 ` Eric McDonald 2003-08-27 16:37 ` Jim Kingdon 1 sibling, 0 replies; 32+ messages in thread From: Eric McDonald @ 2003-08-27 16:17 UTC (permalink / raw) To: xconq7 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. ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: New Xconq Windows Executable 2003-08-27 4:29 New Xconq Windows Executable Eric McDonald 2003-08-27 16:17 ` Eric McDonald @ 2003-08-27 16:37 ` Jim Kingdon 2003-08-27 17:20 ` Eric McDonald 1 sibling, 1 reply; 32+ messages in thread From: Jim Kingdon @ 2003-08-27 16:37 UTC (permalink / raw) To: mcdonald; +Cc: xconq7 > 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). ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: New Xconq Windows Executable 2003-08-27 16:37 ` Jim Kingdon @ 2003-08-27 17:20 ` Eric McDonald 2003-08-27 18:40 ` Hans Ronne 2003-08-28 13:38 ` Juergen Ruehle 0 siblings, 2 replies; 32+ messages in thread From: Eric McDonald @ 2003-08-27 17:20 UTC (permalink / raw) To: Jim Kingdon; +Cc: xconq7 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 ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: New Xconq Windows Executable 2003-08-27 17:20 ` Eric McDonald @ 2003-08-27 18:40 ` Hans Ronne 2003-08-27 19:53 ` Eric McDonald 2003-08-28 13:38 ` Juergen Ruehle 1 sibling, 1 reply; 32+ messages in thread From: Hans Ronne @ 2003-08-27 18:40 UTC (permalink / raw) To: Eric McDonald; +Cc: xconq7 >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 ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: New Xconq Windows Executable 2003-08-27 18:40 ` Hans Ronne @ 2003-08-27 19:53 ` Eric McDonald 2003-08-28 3:26 ` Hans Ronne 0 siblings, 1 reply; 32+ messages in thread From: Eric McDonald @ 2003-08-27 19:53 UTC (permalink / raw) To: Hans Ronne; +Cc: xconq7 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 ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: New Xconq Windows Executable 2003-08-27 19:53 ` Eric McDonald @ 2003-08-28 3:26 ` Hans Ronne 0 siblings, 0 replies; 32+ messages in thread From: Hans Ronne @ 2003-08-28 3:26 UTC (permalink / raw) To: Eric McDonald; +Cc: xconq7 >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 ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: New Xconq Windows Executable 2003-08-27 17:20 ` Eric McDonald 2003-08-27 18:40 ` Hans Ronne @ 2003-08-28 13:38 ` Juergen Ruehle 2003-08-29 0:44 ` Eric McDonald ` (2 more replies) 1 sibling, 3 replies; 32+ messages in thread From: Juergen Ruehle @ 2003-08-28 13:38 UTC (permalink / raw) To: Eric McDonald; +Cc: xconq7 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 ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: New Xconq Windows Executable 2003-08-28 13:38 ` Juergen Ruehle @ 2003-08-29 0:44 ` Eric McDonald 2003-08-29 8:35 ` Eric McDonald 2003-08-29 9:06 ` Hans Ronne 2 siblings, 0 replies; 32+ messages in thread From: Eric McDonald @ 2003-08-29 0:44 UTC (permalink / raw) To: Juergen Ruehle; +Cc: xconq7 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 ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: New Xconq Windows Executable 2003-08-28 13:38 ` Juergen Ruehle 2003-08-29 0:44 ` Eric McDonald @ 2003-08-29 8:35 ` Eric McDonald 2003-08-29 15:22 ` Juergen Ruehle 2003-08-29 9:06 ` Hans Ronne 2 siblings, 1 reply; 32+ messages in thread From: Eric McDonald @ 2003-08-29 8:35 UTC (permalink / raw) To: Juergen Ruehle; +Cc: xconq7 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 ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: New Xconq Windows Executable 2003-08-29 8:35 ` Eric McDonald @ 2003-08-29 15:22 ` Juergen Ruehle 2003-08-30 5:47 ` Eric McDonald 0 siblings, 1 reply; 32+ messages in thread From: Juergen Ruehle @ 2003-08-29 15:22 UTC (permalink / raw) To: Eric McDonald; +Cc: xconq7 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. ===================================================== ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: New Xconq Windows Executable 2003-08-29 15:22 ` Juergen Ruehle @ 2003-08-30 5:47 ` Eric McDonald 0 siblings, 0 replies; 32+ messages in thread From: Eric McDonald @ 2003-08-30 5:47 UTC (permalink / raw) To: Juergen Ruehle; +Cc: xconq7 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 ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: New Xconq Windows Executable 2003-08-28 13:38 ` Juergen Ruehle 2003-08-29 0:44 ` Eric McDonald 2003-08-29 8:35 ` Eric McDonald @ 2003-08-29 9:06 ` Hans Ronne 2003-08-29 15:57 ` Eric McDonald ` (2 more replies) 2 siblings, 3 replies; 32+ messages in thread From: Hans Ronne @ 2003-08-29 9:06 UTC (permalink / raw) To: Juergen Ruehle; +Cc: xconq7 >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 ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: New Xconq Windows Executable 2003-08-29 9:06 ` Hans Ronne @ 2003-08-29 15:57 ` Eric McDonald 2003-09-05 4:54 ` Tcl/Tk Interface Unification (was Re: New Xconq Windows Executable) Eric McDonald 2003-09-08 17:46 ` Tcl/Tk Interface Unification (was Re: New Xconq Windows Executable) Eric McDonald 2 siblings, 0 replies; 32+ messages in thread From: Eric McDonald @ 2003-08-29 15:57 UTC (permalink / raw) To: Hans Ronne; +Cc: Juergen Ruehle, xconq7 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. ^ permalink raw reply [flat|nested] 32+ messages in thread
* Tcl/Tk Interface Unification (was Re: New Xconq Windows Executable) 2003-08-29 9:06 ` Hans Ronne 2003-08-29 15:57 ` Eric McDonald @ 2003-09-05 4:54 ` Eric McDonald 2003-09-05 15:06 ` Hans Ronne 2003-09-08 17:46 ` Tcl/Tk Interface Unification (was Re: New Xconq Windows Executable) Eric McDonald 2 siblings, 1 reply; 32+ messages in thread From: Eric McDonald @ 2003-09-05 4:54 UTC (permalink / raw) To: Hans Ronne; +Cc: xconq7, Juergen Ruehle 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 ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: Tcl/Tk Interface Unification (was Re: New Xconq Windows Executable) 2003-09-05 4:54 ` Tcl/Tk Interface Unification (was Re: New Xconq Windows Executable) Eric McDonald @ 2003-09-05 15:06 ` Hans Ronne 2003-09-05 15:51 ` Eric McDonald 2003-09-15 3:43 ` Tcl/Tk Interface Unification Eric McDonald 0 siblings, 2 replies; 32+ messages in thread From: Hans Ronne @ 2003-09-05 15:06 UTC (permalink / raw) To: Eric McDonald; +Cc: xconq7, Juergen Ruehle >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 ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: Tcl/Tk Interface Unification (was Re: New Xconq Windows Executable) 2003-09-05 15:06 ` Hans Ronne @ 2003-09-05 15:51 ` Eric McDonald 2003-09-06 6:05 ` Hans Ronne 2003-09-15 3:43 ` Tcl/Tk Interface Unification Eric McDonald 1 sibling, 1 reply; 32+ messages in thread From: Eric McDonald @ 2003-09-05 15:51 UTC (permalink / raw) To: Hans Ronne; +Cc: xconq7, Juergen Ruehle 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 ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: Tcl/Tk Interface Unification (was Re: New Xconq Windows Executable) 2003-09-05 15:51 ` Eric McDonald @ 2003-09-06 6:05 ` Hans Ronne 0 siblings, 0 replies; 32+ messages in thread From: Hans Ronne @ 2003-09-06 6:05 UTC (permalink / raw) To: Eric McDonald; +Cc: xconq7, Juergen Ruehle >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 ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: Tcl/Tk Interface Unification 2003-09-05 15:06 ` Hans Ronne 2003-09-05 15:51 ` Eric McDonald @ 2003-09-15 3:43 ` Eric McDonald 2003-09-15 3:50 ` Hans Ronne 1 sibling, 1 reply; 32+ messages in thread From: Eric McDonald @ 2003-09-15 3:43 UTC (permalink / raw) To: Hans Ronne; +Cc: xconq7 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 ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: Tcl/Tk Interface Unification 2003-09-15 3:43 ` Tcl/Tk Interface Unification Eric McDonald @ 2003-09-15 3:50 ` Hans Ronne 2003-09-15 14:32 ` Eric McDonald 0 siblings, 1 reply; 32+ messages in thread From: Hans Ronne @ 2003-09-15 3:50 UTC (permalink / raw) To: Eric McDonald; +Cc: xconq7 >> 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 ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: Tcl/Tk Interface Unification 2003-09-15 3:50 ` Hans Ronne @ 2003-09-15 14:32 ` Eric McDonald 2003-09-15 18:39 ` Hans Ronne 0 siblings, 1 reply; 32+ messages in thread From: Eric McDonald @ 2003-09-15 14:32 UTC (permalink / raw) To: Hans Ronne; +Cc: xconq7 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 ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: Tcl/Tk Interface Unification 2003-09-15 14:32 ` Eric McDonald @ 2003-09-15 18:39 ` Hans Ronne 2003-09-15 19:38 ` Eric McDonald 2003-09-16 13:53 ` Build system overhaul (Was: Tcl/Tk Interface Unification) Juergen Ruehle 0 siblings, 2 replies; 32+ messages in thread From: Hans Ronne @ 2003-09-15 18:39 UTC (permalink / raw) To: Eric McDonald; +Cc: xconq7 >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 ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: Tcl/Tk Interface Unification 2003-09-15 18:39 ` Hans Ronne @ 2003-09-15 19:38 ` Eric McDonald 2003-09-15 23:31 ` Hans Ronne 2003-09-16 13:53 ` Build system overhaul (Was: Tcl/Tk Interface Unification) Juergen Ruehle 1 sibling, 1 reply; 32+ messages in thread From: Eric McDonald @ 2003-09-15 19:38 UTC (permalink / raw) To: Hans Ronne; +Cc: xconq7 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 ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: Tcl/Tk Interface Unification 2003-09-15 19:38 ` Eric McDonald @ 2003-09-15 23:31 ` Hans Ronne 0 siblings, 0 replies; 32+ messages in thread From: Hans Ronne @ 2003-09-15 23:31 UTC (permalink / raw) To: Eric McDonald; +Cc: xconq7 >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 ^ permalink raw reply [flat|nested] 32+ messages in thread
* Build system overhaul (Was: Tcl/Tk Interface Unification) 2003-09-15 18:39 ` Hans Ronne 2003-09-15 19:38 ` Eric McDonald @ 2003-09-16 13:53 ` Juergen Ruehle 2003-09-16 18:15 ` Eric McDonald 2003-09-16 20:23 ` Eric McDonald 1 sibling, 2 replies; 32+ messages in thread From: Juergen Ruehle @ 2003-09-16 13:53 UTC (permalink / raw) To: xconq7; +Cc: Eric McDonald, Hans Ronne 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 ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: Build system overhaul (Was: Tcl/Tk Interface Unification) 2003-09-16 13:53 ` Build system overhaul (Was: Tcl/Tk Interface Unification) Juergen Ruehle @ 2003-09-16 18:15 ` Eric McDonald 2003-09-16 20:23 ` Eric McDonald 1 sibling, 0 replies; 32+ messages in thread From: Eric McDonald @ 2003-09-16 18:15 UTC (permalink / raw) To: Juergen Ruehle; +Cc: xconq7, Hans Ronne 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 ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: Build system overhaul (Was: Tcl/Tk Interface Unification) 2003-09-16 13:53 ` Build system overhaul (Was: Tcl/Tk Interface Unification) Juergen Ruehle 2003-09-16 18:15 ` Eric McDonald @ 2003-09-16 20:23 ` Eric McDonald 2003-09-17 10:32 ` Hans Ronne 2003-09-17 15:54 ` Juergen Ruehle 1 sibling, 2 replies; 32+ messages in thread From: Eric McDonald @ 2003-09-16 20:23 UTC (permalink / raw) To: Juergen Ruehle; +Cc: xconq7, Hans Ronne 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 ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: Build system overhaul (Was: Tcl/Tk Interface Unification) 2003-09-16 20:23 ` Eric McDonald @ 2003-09-17 10:32 ` Hans Ronne 2003-09-17 15:54 ` Juergen Ruehle 1 sibling, 0 replies; 32+ messages in thread From: Hans Ronne @ 2003-09-17 10:32 UTC (permalink / raw) To: Eric McDonald; +Cc: Juergen Ruehle, xconq7 >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 ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: Build system overhaul (Was: Tcl/Tk Interface Unification) 2003-09-16 20:23 ` Eric McDonald 2003-09-17 10:32 ` Hans Ronne @ 2003-09-17 15:54 ` Juergen Ruehle 2003-09-18 2:37 ` Build system overhaul Eric McDonald 1 sibling, 1 reply; 32+ messages in thread From: Juergen Ruehle @ 2003-09-17 15:54 UTC (permalink / raw) To: Eric McDonald; +Cc: xconq7, Hans Ronne 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 ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: Build system overhaul 2003-09-17 15:54 ` Juergen Ruehle @ 2003-09-18 2:37 ` Eric McDonald 0 siblings, 0 replies; 32+ messages in thread From: Eric McDonald @ 2003-09-18 2:37 UTC (permalink / raw) To: Juergen Ruehle; +Cc: xconq7, Hans Ronne 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 ^ permalink raw reply [flat|nested] 32+ messages in thread
* Tcl/Tk Interface Unification (was Re: New Xconq Windows Executable) 2003-08-29 9:06 ` Hans Ronne 2003-08-29 15:57 ` Eric McDonald 2003-09-05 4:54 ` Tcl/Tk Interface Unification (was Re: New Xconq Windows Executable) Eric McDonald @ 2003-09-08 17:46 ` Eric McDonald 2 siblings, 0 replies; 32+ messages in thread From: Eric McDonald @ 2003-09-08 17:46 UTC (permalink / raw) To: Hans Ronne; +Cc: xconq7 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. :-) ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: New Xconq Windows Executable
@ 2003-08-27 18:04 Bill Macon
0 siblings, 0 replies; 32+ messages in thread
From: Bill Macon @ 2003-08-27 18:04 UTC (permalink / raw)
To: xconq7
This would be much more convenient, especially for new users with no Linux
or Cygwin experience. If the new version of Xconq could package ALL
required files/directories into a Windows installation program, that would
be ideal. Download one file, hit "Install," and then play. Future updates
to binaries or game modules could be made available as a patch file. The
idea should be to keep this as simple as possible to bring in new players -
hence new ideas and game mods.
Bill
>From: Eric McDonald <mcdonald@phy.cmich.edu>
>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.
_________________________________________________________________
MSN 8: Get 6 months for $9.95/month. http://join.msn.com/?page=dept/dialup
^ permalink raw reply [flat|nested] 32+ messages in thread
end of thread, other threads:[~2003-09-17 15:54 UTC | newest] Thread overview: 32+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2003-08-27 4:29 New Xconq Windows Executable Eric McDonald 2003-08-27 16:17 ` Eric McDonald 2003-08-27 16:37 ` Jim Kingdon 2003-08-27 17:20 ` Eric McDonald 2003-08-27 18:40 ` Hans Ronne 2003-08-27 19:53 ` Eric McDonald 2003-08-28 3:26 ` Hans Ronne 2003-08-28 13:38 ` Juergen Ruehle 2003-08-29 0:44 ` Eric McDonald 2003-08-29 8:35 ` Eric McDonald 2003-08-29 15:22 ` Juergen Ruehle 2003-08-30 5:47 ` Eric McDonald 2003-08-29 9:06 ` Hans Ronne 2003-08-29 15:57 ` Eric McDonald 2003-09-05 4:54 ` Tcl/Tk Interface Unification (was Re: New Xconq Windows Executable) Eric McDonald 2003-09-05 15:06 ` Hans Ronne 2003-09-05 15:51 ` Eric McDonald 2003-09-06 6:05 ` Hans Ronne 2003-09-15 3:43 ` Tcl/Tk Interface Unification Eric McDonald 2003-09-15 3:50 ` Hans Ronne 2003-09-15 14:32 ` Eric McDonald 2003-09-15 18:39 ` Hans Ronne 2003-09-15 19:38 ` Eric McDonald 2003-09-15 23:31 ` Hans Ronne 2003-09-16 13:53 ` Build system overhaul (Was: Tcl/Tk Interface Unification) Juergen Ruehle 2003-09-16 18:15 ` Eric McDonald 2003-09-16 20:23 ` Eric McDonald 2003-09-17 10:32 ` Hans Ronne 2003-09-17 15:54 ` Juergen Ruehle 2003-09-18 2:37 ` Build system overhaul Eric McDonald 2003-09-08 17:46 ` Tcl/Tk Interface Unification (was Re: New Xconq Windows Executable) Eric McDonald 2003-08-27 18:04 New Xconq Windows Executable Bill Macon
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).