public inbox for xconq7@sourceware.org
 help / color / mirror / Atom feed
From: "Brandon J. Van Every" <vanevery@indiegamedesign.com>
To: "xconq" <xconq7@sources.redhat.com>
Subject: RE: Standardizing the Windows build
Date: Sat, 08 Nov 2003 01:29:00 -0000	[thread overview]
Message-ID: <OOEALCJCKEBJBIJHCNJDKEFPGLAB.vanevery@indiegamedesign.com> (raw)
In-Reply-To: <Pine.LNX.4.44.0311071833300.10293-100000@leon.phy.cmich.edu>

From: Eric McDonald [mailto:mcdonald@phy.cmich.edu]
> On Fri, 7 Nov 2003, Brandon J. Van Every wrote:
> >
> > - TCL distributions.  Eric thinks the TCL binary currently
> > distributed with Cygwin is broken.  I'm not sure myself,
>
> Actually, I'm the one who isn't sure. What I am pretty sure about
> 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, and is not a property of the current
standard Cygwin distribution, then you didn't download a clean Cygwin
distribution and check it.  You also said you built your own TCL from
sources some time ago and never used the Cygwin binary distribution.
Either sanity check it yourself, or accept that the current Cygwin TCL
binaries are what they are.

> > - Religion about commercial IDEs.  If most of you think MS
> > Visual Studio
> > is Evil, then we aren't going to get anywhere.  Most of us Windoze
>
> 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.  You've suggested to me that to do Xconq
under Windoze right now, it'll take "fiddling."  I certainly did a lot
of fiddling between Freeciv and Xconq last week, and I won't do it
anymore.  Nor will Windoze developers in general.  It was a complete
waste of time, 1 solid week down the drain.  I can't spend time like
that, for nothing.

There should be at least 1 approved, supported way.  It should be the
primary, expected way.  If you personally want to provide support for
secondary ways, feel free.  But there should be a primary, expected way,
that the vast majority of Windoze developers and developer wannabes use.

The policy should be, "We do this, we stress test it, and we know that
it works.  If you want to do something else, it may work, but we don't
stress test it.  We may not be willing to put any energy into making it
work."  That's generally what is meant by "standardized."

> I think it can and should be an
> alternative though. And if you make it a viable alternative, I
> can't imagine anyone complaining.

'Cept me.  Why should I support a Windoze build that nobody else will
stress test and develop with?  I shouldn't.  It would make more sense to
find a project that isn't Linux freeware centric.  No sense wasting time
on things that other people don't want and don't need.

> It's hard to be a menace to GPL'd code unless you're stealing
> copyrights or violating the rather liberal terms of the license.

The code cannot be menaced, but a developer team definitely can be.  Or
more likely, a potential contributor can be marginalized.  There's
nothing stopping me from taking the Xconq code and doing whatever I'd
like with it within the terms of the license.  I've certainly considered
it.  But, that doesn't give me too many advantages over just coding my
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.


Cheers,                     www.indiegamedesign.com
Brandon Van Every           Seattle, WA

Taking risk where others will not.

  reply	other threads:[~2003-11-08  0:40 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-11-07 23:46 Brandon J. Van Every
2003-11-08  0:40 ` Eric McDonald
2003-11-08  1:29   ` Brandon J. Van Every [this message]
2003-11-08  1:34     ` Eric McDonald
2003-11-08  2:57       ` Brandon J. Van Every
2003-11-08  1:56 ` Hans Ronne
2003-11-08  2:33   ` Eric McDonald
2003-11-08  2:55     ` Hans Ronne
2003-11-08 11:38       ` Brandon J. Van Every
2003-11-08 22:27         ` Hans Ronne
2003-11-08 22:33           ` SDL and 3D Brandon J. Van Every
2003-11-08 23:29             ` Eric McDonald
2003-11-09  2:45             ` Hans Ronne
2003-11-09  3:33               ` whose Windoze build it is anyways Brandon J. Van Every
2003-11-09 12:52                 ` Stan Shebs
2003-11-08  3:06     ` Windows native UIs Brandon J. Van Every
2003-11-08 13:58       ` Hans Ronne
2003-11-08  3:10   ` The gory Xconq kernel Brandon J. Van Every
2003-11-08 13:06     ` Hans Ronne
2003-11-08 22:59       ` Ease of MSVC build Brandon J. Van Every
2003-11-09  0:28         ` Eric McDonald
2003-11-09  0:42           ` Brandon J. Van Every
2003-11-09  1:54             ` Brandon J. Van Every
2003-11-09  4:41       ` easy build trees for non-Xconq gurus Brandon J. Van Every

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=OOEALCJCKEBJBIJHCNJDKEFPGLAB.vanevery@indiegamedesign.com \
    --to=vanevery@indiegamedesign.com \
    --cc=xconq7@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).