This is the mail archive of the
xconq7@sources.redhat.com
mailing list for the Xconq project.
RE: Standardizing the Windows build
- From: Eric McDonald <mcdonald at phy dot cmich dot edu>
- To: "Brandon J. Van Every" <vanevery at indiegamedesign dot com>
- Cc: xconq <xconq7 at sources dot redhat dot com>
- Date: Fri, 7 Nov 2003 20:29:23 -0500 (EST)
- Subject: RE: Standardizing the Windows build
On Fri, 7 Nov 2003, Brandon J. Van Every wrote:
> From: Eric McDonald [mailto:mcdonald@phy.cmich.edu]
> > On Fri, 7 Nov 2003, Brandon J. Van Every wrote:
> > is that the Cygwin Tcl installation on _your_ system is broken. If
> > your TCL_INCLUDE_SPEC points to a nonexistent directory, then
> > something isn't right. (And if this argument is going to reach
> > flamewar crescendo again, let's take it back off-list.)
>
> Eric, with all due respect, if you believe
> TCL_INCLUDE_SPEC=C:\nonexistent\include
> is somehow unique to my machine,
I didn't say it was unique to your machine, but I am not going to
generalize it to everyone either. Hence the "I'm not so sure".
> standard Cygwin distribution, then you didn't download a clean Cygwin
> distribution and check it.
That's correct. I didn't, and I didn't tell you that I did either.
> You also said you built your own TCL from
> sources some time ago and never used the Cygwin binary distribution.
Never _successfully_ used the Cygwin Tcl/Tk binaries (which were
old anyway).
> Either sanity check it yourself, or accept that the current Cygwin TCL
> binaries are what they are.
Which is what?
> > It's not a matter of being evil. I simply would not want to say
> > that I would want that to be the only approved, supported way to
> > build Xconq under Windows.
>
> As it stands now, there is no particular approved, supported way to
> build Xconq under Windows.
That would seem to be the case. I suppose I should sit down
sometime and recreate the way I built Tcl/Tk on Cygwin, or else
go entirely to ActiveTcl for everything. Then there would be at
least one way.
> You've suggested to me that to do Xconq
> under Windoze right now, it'll take "fiddling."
Yes. To build it, anyway. To play it or design games with it, no;
that "issue" has recently been addressed.
> There should be at least 1 approved, supported way. It should be the
> primary, expected way.
Sounds good.
> secondary ways, feel free. But there should be a primary, expected way,
> that the vast majority of Windoze developers and developer wannabes use.
Sounds good.
> The policy should be, "We do this, we stress test it, and we know that
> it works.
If you wish to volunteer to be the person who upholds that policy,
then please be my guest.
> stress test it. We may not be willing to put any energy into making it
> work."
Or at least not put any energy into it at this moment.
> > can't imagine anyone complaining.
>
> 'Cept me. Why should I support a Windoze build that nobody else will
> stress test and develop with?
I ask myself the same question.
>I shouldn't.
Then why should I? You seem to be complaining that we didn't do
this for you, when you yourself wouldn't do it for others.
> nothing stopping me from taking the Xconq code and doing whatever I'd
> like with it within the terms of the license.
That's correct. One of the very nice features of such a
license....
> own game from scratch. The advantage is to work with an extant team
> that knows the code, provides new features, bugfixes, labor if they're
> interested in some idea, etc.
Yes.
Eric