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 -- http://mail.python.org/mailman/listinfo/python-list
