Which compiler will Python 2.5 / Windows (Intel) be built with?

[meyer at mesw.de]

Martin,

Martin v. Löwis wrote:
> > * 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?

In bigger (i.e. real-world) projects, it can be a lot of hassle
switching to another compiler, even from the same vendor. Of course, in
theory C and C++ compilers should be compatible, but in practice
there's lots of small things that are implemented differently. Among
them are #pragmas, the support for precompiled headers, template
instantiation, different semantics for "half-legal" constructs etc.
Also, some syntactic constructs which compile on one compiler are
rejected by another compiler. Further, often code implicitely depends
on the behaviour of one single compiler, although the developer doesn't
really know that. Of course you can cry fool on the developer that
wrote the code and blame him for not following the C-whatever spec, or
not using the "correct" way to do X, but fact is, there's always stuff
that will not work when switching to another compiler. And there's a
bunch of other stuff that will appear to work but "activate" bugs in
the control structure that were there previously but luckily did not
manifest with the other compiler.

Btw, the same goes for different versions of libraries, say different
versions of wxWidgets, MFC, Visual Basic (anyone tried to switch from
VB6 to VB.NET?) and of course also for different versions of Java and
its libraries.

> > * 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?

We have lots of stuff written in VC++6 which is not
distutils-compatible, and we can't really switch that code over to GCC
anytime soon, see above. All in all, we would end up compiling
something with VC, linking it with GCC to another VC app (Python). No,
thanks.

> 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.

The question is, is it cheaper and more hassle-free to spend the time
to "find a way to make it work" and hope everything goes smoothly
(remember, the fact, that it says "Linker results: 0 errors / 0
warnings" does not mean that the app will work as expected and as
tested before) or to buy VC (which costs a mere few hundred dollars).

Bottom Line: As I said before, I don't have a problem using VC2003 or
anything. It's by far the cheapest and easiest way just to buy VC2003
and be done with it, than to fiddle around with GCC or anything. I just
think that Python should use the best technology available at the time
of release, which is VC2005 on Windows. But as I indicated before, of
course I do understand the argument that the release cycle has already
been planned and should not be changed, so we'll just live with it as
it is now.


Markus