Development_Environment/Commentary

(9/2/2002) DWM OK, I poured all my stamina for over a week, including almost three weekends' worth of days off, into putting this development environment, and now it's time to sit back and assess the results.

The compiler (MinGW gcc)
- No real problems. It's better in terms of C++ language support than VC6, perhaps on par with VC7.
- It seems a bit slow, but not too bad, and this is only an impression -- I don't have VC6 installed for comparison.
- Quality of code generated? I have no idea.
- The standard library is a bit out of date, but STLport fills the gap fine. I don't know how good other crucial libraries are yet, because I haven't needed them -- things like Win32 API, DirectX 8, etc. Some of these have to be gathered from various sources.
Jam
- I think I understand the basic tool pretty well.
- Using the Boost.Build system with it adds a lot of complexity that I am having trouble mastering. OTOH it provides a lot of definitions that let you do simple things with no fuss.
- There is a new version of Boost.Build (and slightly modified BJam) in active development.
uBLAS
- Has some rough edges, docs are scanty.
- Am starting to understand how to use it.
- I have high expectations for its performance.
GDB -- the GNU Debugger. This is not part of the base MinGW package; I haven't posted any info on it yet, outside of this right here.
- The MinGW ports are buggy in at least one way that is very irritating. The MinGW compiler embeds well-formed Windows-style source file names in the binary debug info, but the GDB ports I've tried so far can't interpret it. To work around this, you have tell it each directory to look in for source code. Particularly irritating when using template-based libraries like uBLAS!
- Failed assertions and unhandled exceptions don't break in the debugger -- they end the program! I have found several discussions of this problem on the net, but no solutions. I think that a solution for the assertions is possible, but haven't gotten it to work yet. For the exceptions -- no idea. Might have to move to a newer version of the compiler & runtime libraries, but the MinGW ports are only in beta right now. Very disappointing.

All in all, I'm now more amenable to using a commercial compiler suite for main development on Win32. The GNU tools work fine on Linux -- I attribute all these problems to the Win32 ports. I could make a practice of verifying compilability there for subsystems that need to work on the server.

OTOH, here's another thought: Debugging full-screen graphical programs is hard without either two monitors or (better) two computers. GDB can be used for remote debugging. Also, it is fairly common to cross-compile Win32 programs on a Linux system. So one could imagine having a Linux box for development work, running the program on your Win32 box. You'd do all builds on Linux, and run GDB's front end there. How many of us have at least two computers, one running Linux, with a network or serial cable between them? <raises hand> I doubt this idea will appeal to most of you, but I thought it worth airing.

nfs I really have just one computer (the other is a laptop), but the idea of a second monitor sounds good. It will probably be a necessity once we make real progress. Right now, the demo game I'm creating is using windowed mode to make debugging on one monitor easier.

JDH Don't ask me how many computers I've got - I'll blush (mind you not all of them work so well and some of them run on steam). I'd be happy with either approach. I don't mind learning another environment OTOH my shiny new laptop has the ability to drive two screens and so would make a pretty decent development environment. Thanks for putting all that effort into this.

DWM Let me clarify and expand a bit, seeing as it was (once again) pretty late when I tossed off that last bit. I had several goals in setting this all up:

Investigate one possible alternative to using MS's stuff, and a cheap one at that with no worry about "Is this pirating?" or "What will this cost me when (not if) I have to buy a legit copy for SDx work?"
Investigate a way of verifying gcc-compilability of code that may need to run on a Linux server some day.

As a result of my investigations, I'm leery of using the open source Win32 ports for developing the client software. I'm sure it could be made to work. The problems I mentioned above are not showstoppers, and I failed to mention an important possible remedy for the gdb problem: Fix it! (Use the Source, Luke.) OTOH, I don't doubt there will be further annoyances of this ilk, and, well, fixing open source software doesn't get a game built any faster.

For the server-compilability problem, the obvious fix is to just build the damn stuff periodically on a Linux box.

So I guess the questions to this distinguished group of peers are:

Do you have the desire and fortitude to build on my efforts and use Open Source software for client development, realizing that various distractions will ensue? There would be some benefits, but none clearly and directly serving SDx, as I see it: Learning the Open Source techniques and tools, perhaps the satisfaction of contributing some stuff back, the possibility of customizing tools to suit your/our needs.
If the consensus to the above is "no", then what alternative do you propose?
- Will someone step forward and investigate whether VC7 licensing at Creative allows us to install copies at home? Can we arrange to borrow the well-guarded installation media then? What would VC7 cost outright? What do we do to help Steve with this?
- Would you want to use the VC6 that your familiar with? I don't, personally, but I could live with a clear consensus decision to stick with it. We know that licensing at Creative allows (most of?) us to install a copy of VC6 at home. Chances are we could get it cheap for Steve, since it's not the latest version anymore.
- If we reject VC6 and it turns out that we would have to buy VC7, then should we stick with MS or investigate alternatives? How big an issue will price be for people to buy their own tools? VC has a reasonably good reputation as an optimizing compiler, but there are better ones out there, e.g. Intel's, but I don't know a lot about this. And then there is Borland/Inprise/Borland. My wife uses it and seems pretty pleased with recent releases, although she's major version behind. It's not noticeably cheaper than VC, AFAIK.

BTW, it should be clear that I'm a bit of a stickler for playing by the rules with licensing. I'm not going to berate people for sharing software they shouldn't, and I don't claim to always be an angel myself, but I don't want to develop any sort of strategy that explicitly requires pirating. At this point at least, what you do in the privacy of your own home is your business, but think about the possibility that what we're working on will eventually become a shared asset that you should be contributing without worrisome encumbrances. 'Nuff said, I hope.

Let's have a lively discussion on this here. Let's explore the possibilities so that we can come to a quick resolution. I want to get on with writing code!

Note that if we drop the open source alternative, little of my work will be lost: I would likely continue to use BJam for server-based builds, when I get around to setting them up.

JDH My original thought on this is that we'd take an, ahem, liberal attitude towards licensing. I had imagined that we would use the same tools that we used at work for sake of convenience and familiarity and then when we moved past some yet to be determined point in development when we felt that there was a large chance of this becoming a commercial venture then we would all pony up for legit tools. I know that there are several licenses that allow one to buy software dev tools for "personal use" at a reduced rate as long as you don't develop commercial software - MS used to have this option available but I've no idea if it still exists.

This approach has the problem of being "questionable" (but one which I'd expect we'd fix at a more appropriate point in time) it also has the problem of leaving Istvan out in the cold. However, I presume that Istvan could be counted as a student at present and thus could buy his tools at a reduced rate (if the "personal use" license doesn't play out)

That's how I'd thought things would play out with the IDE and at the time I thunk it we were using VC6 so I was thinking that's what we'd primarily use. I'm not particularly attached to the idea though and would be happy to develop in a Linux based environment and I think that problems we encounter will most likely have fixes already out there somewhere.

DWM For licensing, let's just say "every man for himself" for now, I'm fine with that.

I'm being pushy about getting a consensus because it's hard work to make software portable between compilers, and I want to avoid it where I don't see a need for it -- i.e. standardize on one toolset for Win32, one for Linux servers.

VC6 leaves me a bit cold because other compilers are generally quite a bit more standards-conforming, and I've seen indication that some free software is feeling an urge to drop support for VC6. For instance, once gentleman on the Boost mailing lists, in reviews of the vector/matrix math library uBLAS, was urging the developers not to hobble the product by catering to older, broken compilers. (In context, he was referring specifically to VC6.)

VC7 I could live with, but I don't feel I've gotten a definitive answer about whether we can get a free ride from Creative. (If it ain't legit, it won't happen via Creative these days, they've gotten quite tight about release media as you know.)

Interestingly, I just saw DevStudio VC++ (specifically w/o C# & VB, maybe other features missing) on MS's web site for $107 -- about one-tenth what they charge for DevStudio Pro with C# and VB. There's very little info though, hard to know if it supports all modes of development. In the past, they've had versions sans optimization, dynamic linking, etc.

For the moment I'll continue puttering along with OS stuff.

DWM (9/12/2002) More about compilers on Windows. Yadda yadda yadda... Born of frustration with tools and language support:

DWM (9/13/2002) I've purchased a copy of Comeau C++ for Windows, intending to use it with VC6. When VC 7.1 is out, we can consider using that if we can afford to get copies. For UNIX builds, another $50 gets us Comeau C++ for Linux, using gcc as the back-end. As soon as I have my copy, I'll investigate what the resulting build/debug environment is like.

For more info on Comeau C++, see http://www.comeaucomputing.com. If you read any C++ related newsgroups or mailing lists, you've almost certainly seen this compiler mentioned. It's widely reputed to be the most standards-conforming C++ compiler around. Greg Comeau has been working with C++ for over a decade; try searching Google Groups sometime for messages by him.

I've introspected a bit about why I keep obsessing about getting a good C++ compiler, and decided that it's because I'm lazy. I want to be able to use nifty time-saving libraries like Boost and Loki, which rely on advanced C++ features to work fully and properly. I'm really reluctant to spend time writing things like smart pointer classes and such, having done way too much of this in the past already. And most of what we write below the UI level has to be portable between Windows and UNIX, which usually means dealing with multiple compilers, each with its own mishandling of the C++ language standard. So now I'm pinning my hopes on Comeau C++ to give us a uniform and complete treatment of the language across platforms. Fingers crossed.

DWM (9/15/2002) Comeau C++ update.

You win a few, you lose a few.

The Comeau C++ compiler (referred to as 'como') is indeed wonderful in its handling of the C++ language. It found a bug in uBLAS for me, and a couple of minor issues in my code, and has generally given me no compilation problems, once installed correctly. (The installation process is a bit involved, and includes some workaround steps for hopelessly non-standard code in some MS headers.)

Integrating it into the builds has been a nightmare, however. como uses some interesting tricks to deal with templates, involving extra files that it generates. These are not a big problem to deal with per se, but como does some silly things like insisting on creating and finding these extra files in the current directory. Comeau Computing says that they're working on this "annoyance". Their support has been stellar. My 'Comeau' mail folder now contains 44 (!) messages (including all sent and received), some of them from Greg Comeau himself, and some of them received after 11 p.m. (They're based in New York, EST, although I suppose they might have some support people in other time zones.)

I figured out how to deal with these problems in simple cases, but it is not yet clear to me how to deal with these template files in the face of static libraries. The email exchanges continue. There is a gross workaround that involves turning these features off, but that's just an interim solution because it causes massive code bloat by instantiating all templates in every object file that they're used.

I've done a little bit of debugging with a Comeau-built program and the VC6 DevStudio, and it's do-able, but not pretty. All the tools are there, but the name mangling is pretty horrific.