[EMAIL PROTECTED] wrote: > thanks for the tip, I wasn't fully aware of that. OTOH, though GCC > might be a theoretical alternative, it isn't a practical one for many > situations: > > * In a professional environment, it opens up another can of potential > problems, where one would rather like to stay with one single > compiler/build system.
That's a theoretic argument to me: Can you name four or five problems out of that can? > * I suppose Python's distutils have to be tweaked to work with GCC No, it should work out of the box. If it doesn't: contributions are welcome. > * The Makefiles/build system will need to be changed to work with the > GCC toolchain If you are using distutils, you don't need a Makefile, and the setup.py won't have to be tweaked. If you are not using distutils, but, say, nmake already, then you will already have an earlier version of the compiler - how else did you create the nmake files in the first place? > * The different semantics of GCC and Microsoft C often need rewriting > some of the code For C code, the semantic differences are really minor. You almost never need any rewriting when moving from MS compilable code to gcc; if you do, it is fairly straight forward to formulate the code so that it compiles with both compilers > * There is no support for MFC/ATL in GCC That's true. > * The code created by the Windows GCC is not as good as the one created > by the Microsoft compiler I never found that relevant for practical purposes. While it is possible to create hand-crafted programs that show a difference, real-world programs are often more limited by the performance of the OS (disk IO, database IO, GUI) than raw processor speed. Still, if you really cannot use gcc, then go ahead and compile with VS 2005. Just make sure you link with mscvr71.dll. If you absolutely need that to work, you will find a way to make it work. Regards, Martin -- http://mail.python.org/mailman/listinfo/python-list
