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

[=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=]

hmm, yet msvcrt4 is obviously preinstalled on each Windows - and its in
Windows Update Process. Its tagged: "4.20 - OS use only. DO NOT
DISTRIBUTE")
Think, in principle its possible to compile against that with
VS2003/2005... ?
( think msvcrt4 is not delivered extra even in the python2.3 installer )

Unfortunately, you also need the header files and an import library
to link against this library. Likewise, for applications that bundle
MFC, you need the corresponding set of header files and libraries.

Microsoft does not provide import libraries for msvcrt4.dll anymore.

Yet if the C runtime lib (distribution) problem is solved, the question
of the compiler becomes irrelevant. Everybody could use his compiler
without worry - a soft recommendation could be in the Python2.5 doc's to
link extensions also against the same common basic ctrl in order to keep
the numer of libs small.

Unfortunately, that is a real technological challenge. Where do you get
the header files and import libraries, and how do you explain to your
compiler to use those instead of the ones it comes with?

there is also a "msvcrt.dll" - also updated by the Windows system. maybe
its on each Windows ? On XP it has version 7. What is this?

It used to be possible to link with it. See

http://msdn2.microsoft.com/en-us/library/abx4dbyh(VS.80).aspx

This is now a "known DLL", and meant for use by system-level components
only.

Maybe most a most simple cutoff criteria with "costs" does it magically.
Basic proposal:

cost = (C1 * module-size - C2 * frequency-of-module-usage)

Unfortunately, that criterion cannot be determined in an objective
manner. It's not possible to determine frequency-of-module-usage
in any meaningful way for existing modules, let alone for modules
that are contributed and to be included only in the upcoming
release.

Regards,
Martin

 

[meyer]

Martin,

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.

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

 

[Scott David Daniels]

Isn't Python for other platforms built with GCC? Seems to me that if it
GCC is good enough for other platforms, it's good enough for Windows.

You clearly misunderstand the interface to the Windows OS & GUI system.
Microsoft provides that interface through its language systems, and has
used that edge to knock off other compilers (such as WatCom) by
providing header files that are not standard C compatible.

--Scott David Daniels
(e-mail address removed)

 

[Roel Schroeven]

Scott David Daniels schreef:

You clearly misunderstand the interface to the Windows OS & GUI system.

Very well possible.

Microsoft provides that interface through its language systems, and has
used that edge to knock off other compilers (such as WatCom) by
providing header files that are not standard C compatible.

It seems that many people successfully use mingw. At work I use a
Borland compiler all the time, without compatibility problems with
Windows' APIs.

But what I meant was not related to interface compatibilities, but to
the performance of the generated code: many people say that the code
generated by gcc is not as well optimized as code generated by
Microsoft's compilers. Yet I never hear complaints about that from
people who use Python on e.g. Linux, where Python is compiled with gcc.
So, while there might be valid reasons not to use mingw, as far as I can
see the optimization capabilities of the compiler are not a compelling
reason.

 

[=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=]

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.

Thanks for the confirmation; that's good enough for me.

Regards,
Martin

 

[Scott David Daniels]

... But what I meant was not related to interface compatibilities, but to
the performance of the generated code: many people say that the code
generated by gcc is not as well optimized as code generated by
Microsoft's compilers. Yet I never hear complaints about that from
people who use Python on e.g. Linux, where Python is compiled with gcc.
So, while there might be valid reasons not to use mingw, as far as I can
see the optimization capabilities of the compiler are not a compelling
reason.

I musunderstood you. I thought you were advocating that Python itself
be built on gcc, obviating many compiler access issues. That wouldn't
work because gcc cannot, by itself (as I understand it) get to all the
nooks and crannies a windows developer may need to traverse. I know I
just repeated my argument here against a strawman, but that was really
for other readers, not for you.

--Scott David Daniels
(e-mail address removed)

 

[Guest]

I musunderstood you. I thought you were advocating that Python itself
be built on gcc, obviating many compiler access issues. That wouldn't
work because gcc cannot, by itself (as I understand it) get to all the
nooks and crannies a windows developer may need to traverse. I know I
just repeated my argument here against a strawman, but that was really
for other readers, not for you.

Even that is incorrect. Python 2.x can be built fully with gcc. It's
PythonWin that includes a lot of C++ and MFC code that won't compile
with gcc. That doesn't preclude to use gcc for Python 2.x compilation,
as long as a msvcrt is selected that can work together with some
version of MFC and the MS C++ RTL.

Regards,
Martin

 

[Roel Schroeven]

Scott David Daniels schreef:

I musunderstood you. I thought you were advocating that Python itself
be built on gcc, obviating many compiler access issues. That wouldn't
work because gcc cannot, by itself (as I understand it) get to all the
nooks and crannies a windows developer may need to traverse. I know I
just repeated my argument here against a strawman, but that was really
for other readers, not for you.

I'm not actively advocating it since I realize I don't know enough about
all the pros and cons, but yes, I would like for Python and other open
source projects to use gcc even on Windows.

It gives me an uneasy feeling when you can't use the source (apart from
just reading it) of open source projects without depending on the whims
of a third party. As an example, look what happened to the Linux kernel
and Bitkeeper. One might argue that Microsoft is not really a third
party since the whole Windows platform is made by them, but the problems
are the same: as far as I understand, Visual Studio Express 2003 is no
longer available, and the 2005 version is not binary compatible.

In my case, I'm even unable to uninstall any modern Microsoft compiler
since AFAICT they all require XP SP2 and I'm stuck with SP1 on my laptop
since SP2 conflicts with the touchpad driver resulting in Windows
blocking on booting, but that only effects me (I hope) and is something
for a whole other rant.

 

[meyer]

(e-mail address removed) schreef:

Isn't Python for other platforms built with GCC? Seems to me that if it
GCC is good enough for other platforms, it's good enough for Windows.

Actually, GCC on Linux does provide worse machine code than say, the
Intel compiler for Linux. This is not a "bug" of GCC, but a feature,
because GCC was created for maximum portability and flexibility, not
for maximum performance on one single platform like the Intel compiler.
But GCC is truly free and can be distributed easily (because it's GPL),
so it is the default compiler for most (if not all) distros at the
moment. Also, there are many free software programs that use special
features of GCC and cannot be compiled using another compiler.

Of course I do acknowledge that often in the real world the IO forms
the bottleneck of a system and the efficiency of the machine code is
somewhat neglegible (other posters pointed that out already).


Markus

 

[Scott David Daniels]

.... Also, there are many free software programs that use special
features of GCC and cannot be compiled using another compiler.

This is precisely what bothers me about standardizing on GCC --
lock-in is lock-in whether you must pay cash or not.

--Scott David Daniels
(e-mail address removed)