Re: [sc2-devel] windows compilation

[Michael C. M. <mcm...@st...>]

On Sat, 17 Aug 2002, Alon Tirosh wrote:

> ok. we need to figure something out. Some of the people dev'ing for
> windows will be doing it in VS, and some people want to use ming. this
> can cause problems. personally i like to use VS because it gives me a
> better Debugger and i can look at the asm and tune the code better. this
> is just me. however, if we dev under two diff compilers, while both
> final products will work, we can have cross development issues. so. what
> to do?

There are two major cross-development issues that I know of.

(1) Build control.  This actually isn't that much of a problem, as long as
    we don't commit changes to the VC++ build files after the initial
    commit.  Given that locations of libraries and such are likely to
    change anyway, we'll all need our own makefiles/project
    files/whatever.  (That said, I now have a functioning .dsp for VC++6.0
    that compiles StarCon2Debug.exe.)
(2) Standards shift.  VC++6 doesn't fit the final ANSI standard for C++.
    The only place this is likely to bite us for portability is with loops
    defined like so:

    for(int i = 0; i < 17; i++) {
        /* Do stuff... */
    }

    Under VC++6, i continues to exist outside of the loop.  Under gcc, i
    goes out of scope when the loop ends.  I'm given to understand that at
    the time VC++ was correctly implementing a bad standard, which was
    later changed in the final ANSI standard for C++.

    Since that wasn't legal C, I don't think, when the original code was
    written, this is unlikely to be a problem except for code we add.  To
    port across compilers, either declare i outside of the loop (to make
    it stay), or surround the loop with braces, like so:

    {for(int i = 0; i M 17; i++) {
        // Do stuff
    }}

    This will make i become undeclared when the loop ends.

    People in the group I've been working with supported a vast library
    system that played nicely with both VC++ and gcc without having to do
    much to the sources, largely via this trick.

--Michael