My only complaint about Python

[Darren Dale]

I love the language. I love the community. My only complaint is that
Python for Windows is built with Visual Studio.

It is too difficult to build python, or a module, from source. This is
what open source is all about, isnt it? I even have a copy of visual
studio, and I still cant build modules from source, because my academic
copy is version 7. As a scientist funded by the NSF, I feel compelled to
do all my work using free software (I feel compelled to use free
software, regardless). And I feel compelled to contribute to the
scientific capabilities of my favorite programming language. But this
compiler issue is a big (and seemingly unnecessary) impediment. Will the
BDFL ever split with Visual Studio?

[Josh Close]

Why not use ActiveState pythong then?

-Josh

On Thu, 19 Aug 2004 11:42:50 -0400, Darren Dale <dd**@cornell.edu> wrote:

I love the language. I love the community. My only complaint is that
Python for Windows is built with Visual Studio.

It is too difficult to build python, or a module, from source. This is
what open source is all about, isnt it? I even have a copy of visual
studio, and I still cant build modules from source, because my academic
copy is version 7. As a scientist funded by the NSF, I feel compelled to
do all my work using free software (I feel compelled to use free
software, regardless). And I feel compelled to contribute to the
scientific capabilities of my favorite programming language. But this
compiler issue is a big (and seemingly unnecessary) impediment. Will the
BDFL ever split with Visual Studio?
--
http://mail.python.org/mailman/listinfo/python-list

[Ralf Schmitt]

Darren Dale <dd**@cornell.edu> writes:

I love the language. I love the community. My only complaint is that
Python for Windows is built with Visual Studio.

It is too difficult to build python, or a module, from source. This is
what open source is all about, isnt it? I even have a copy of visual
studio, and I still cant build modules from source, because my
academic copy is version 7. As a scientist funded by the NSF, I feel
compelled to do all my work using free software (I feel compelled to
use free software, regardless). And I feel compelled to contribute to
the scientific capabilities of my favorite programming language. But
this compiler issue is a big (and seemingly unnecessary)
impediment. Will the BDFL ever split with Visual Studio?

You can build modules using msys/mingw. Instructions can be found at
http://sebsauvage.net/python/mingw.html

--
brainbot technologies ag
boppstrasse 64 . 55118 mainz . germany
fon [phone] . fax [phone]
http://brainbot.com/ mailto:ra**@brainbot.com

[Istvan Albert]

Darren Dale wrote:

I love the language. I love the community. My only complaint is that
Python for Windows is built with Visual Studio.

It is too difficult to build python, or a module, from source.

In all fairness this is more the problem with Microsoft than
python. If they had a free fully-featured compiler then Python
would be compiled with that.

Microsoft seems to have made some half-hearted attempt in
this direction so that is promising.

I know that there are other compilers for windows but their
market penetration is far less and thus expertise to use them
is hard to come by.

I myself am in a very similar position, have a hard time
deploying extension modules on windows. My usual workaround
is to have a second python available via cygwin where I can
compile everything then then use remote procedural calls
via XMPRPC to connect from the windows python. Clearly
this will work only in certain cases.

Istvan.

[David Fraser]

Darren Dale wrote:

I love the language. I love the community. My only complaint is that
Python for Windows is built with Visual Studio.

It is too difficult to build python, or a module, from source. This is
what open source is all about, isnt it? I even have a copy of visual
studio, and I still cant build modules from source, because my academic
copy is version 7. As a scientist funded by the NSF, I feel compelled to
do all my work using free software (I feel compelled to use free
software, regardless). And I feel compelled to contribute to the
scientific capabilities of my favorite programming language. But this
compiler issue is a big (and seemingly unnecessary) impediment. Will the
BDFL ever split with Visual Studio?

I agree. I don't mind it being built with Visual Studio, but out of the
box mingw compatibility would be cool...

[John Hunter]

>>>>> "David" == David Fraser <da****@sjsoft.com> writes:
David> I agree. I don't mind it being built with Visual Studio,
David> but out of the box mingw compatibility would be cool... --
David> http://mail.python.org/mailman/listinfo/python-list

The only thing that needs to be done for mingw compatibility is to
build the import lib, right? It would be nice if the win32 python
shipped with that; it's only 37K gzipped.

I have a batch script to create libpython23.a, for those who are
interested. It requires pexports-0.42h from
http://starship.python.net/crew/kern...orts-0.42h.zip
extracted to C:\Program Files\pexports-0.42h, and of course mingw.

Your paths may vary...

copy c:\windows\system32\python23.dll .
c:\progra~1\pexports-0.42h\bin\pexports python23.dll > python23.def
c:\MinGW\bin\dlltool --dllname python23.dll --def python23.def --output-lib libpython23.a

copy libpython23.a c:\python23\libs
del python23.dll
del libpython23.a

[Peter Maas]

Istvan Albert schrieb:

In all fairness this is more the problem with Microsoft than
python. If they had a free fully-featured compiler then Python
would be compiled with that.

Isn't the free Borland 5.5 compiler full featured?

--
-------------------------------------------------------------------
Peter Maas, M+R Infosysteme, D-52070 Aachen, Tel [phone]
E-mail 'cGV0ZXIubWFhc0BtcGx1c3IuZGU=\n'.decode('base64')
-------------------------------------------------------------------

[Dominic]

I have a batch script to create libpython23.a, for those who are
interested. It requires pexports-0.42h from
http://starship.python.net/crew/kern...orts-0.42h.zip
extracted to C:\Program Files\pexports-0.42h, and of course mingw.

I have successfully built libpython23.a using
implib.exe provided with the free Borland C/C++ command line
compiler package.
Once this is done, cygwin-gcc can be used to create
_native_ windows modules.
If someone is interested I'll try to collect the
necessary commands and flags from my Makefiles.

Ciao,
Dominic

[Istvan Albert]

Dominic wrote:

I have successfully built libpython23.a using
implib.exe provided with the free Borland C/C++ command line
compiler package. Once this is done, cygwin-gcc can be used to create
_native_ windows modules. If someone is interested I'll try to collect the
necessary commands and flags from my Makefiles.

I'm interested. You should even make your copy of
libpython23.a downloadable too.

Istvan,

[David Fraser]

Istvan Albert wrote:

Darren Dale wrote:

I love the language. I love the community. My only complaint is that
Python for Windows is built with Visual Studio.

It is too difficult to build python, or a module, from source.

In all fairness this is more the problem with Microsoft than
python. If they had a free fully-featured compiler then Python
would be compiled with that.

Microsoft seems to have made some half-hearted attempt in
this direction so that is promising.

There's a difference between free and open source. I agree that having
python compilable using a freely available open source compiler is important

David

[Gisle Vanem]

"John Hunter" wrote:

Your paths may vary...

copy c:\windows\system32\python23.dll .
c:\progra~1\pexports-0.42h\bin\pexports python23.dll > python23.def
c:\MinGW\bin\dlltool --dllname python23.dll --def python23.def --output-lib libpython23.a

copy libpython23.a c:\python23\libs
del python23.dll
del libpython23.a

Shouldn't that be "libpython23.dll.a" as per normal conventions
on MingW? I.e. a static lib would be "libpython23.a". But I guess
that's impossible or impractical.

--gv

[Tim Peters]

[Darren Dale[

...
Will the BDFL ever split with Visual Studio?

We should be clear here that this isn't Guido's decision. What you
get on Windows is what you get on all other platforms in this respect:
you get what volunteers show up to produce, year after year after
year. So you get a fine Cygwin port from Jason Tishler, seemingly
toiling all alone, and you get contributions from at least four
developers who do use Visual Studio.

I don't think that's an accident. Most open source jockeys who use
Windows do so because it's needed for their day job, and sticking with
an MS compiler is widely perceived in pointy-hair boss-land as the
safest course on Windows. And it is a first-class IDE, so there's no
pragmatic reason to wrestle with yet another system when the day job
ends. It takes real sweat to get comfortable with any C development
tool chain, and it takes years to become familiar wth each one's
maddening quirks.

I expect that's why Guido still uses Visual Studio when he's running
on Windows (and know it's why I do), but he actually hasn't had
anything to do with the Windows Python releases for years. Things
Will Change when long-term volunteers show up and change them.

[Greg Ewing]

David Fraser wrote:

I agree. I don't mind it being built with Visual Studio, but out of the
box mingw compatibility would be cool...

As a step towards this, it would be useful if it were
distributed with the libpythonXX.a that mingw requires
already built. Then it would just be a matter of giving
the appropriate flag to setup.py when compiling a module.

--
Greg Ewing, Computer Science Dept,
University of Canterbury,
Christchurch, New Zealand
http://www.cosc.canterbury.ac.nz/~greg

[Tim Roberts]

Darren Dale <dd**@cornell.edu> wrote:

.... As a scientist funded by the NSF, I feel compelled to
do all my work using free software (I feel compelled to use free
software, regardless).

Then what on Earth are you doing with Windows?
--
- Tim Roberts, ti**@probo.com
Providenza & Boekelheide, Inc.

[flab ba]

I use Python for mission-critical enterprise level stuff, and I have to
say that on **Windows**, I'd rather it be compiled with MSVC, and not
something like MingW or GCC.

Under no circumstances would I put something in production if it was using
Cygwin.

There is nothing to stop you from compiling Python yourself with the free
Visual C++ Toolkit. Instructions are here:

http://www.vrplumber.com/programming...kit/index.html
http://mail.python.org/pipermail/pyt...ry/042595.html

When the 2005 Toolkit comes out, I have a sneaky suspicion that the
"Starter" pack will be good enough to compile Python - which will be
very cheap (maybe even as low as $50).

An important part of Python for Windows is Mark Hammond's Windows
extensions - I wonder if these rely on a very "windows-savy" compiler like
(Borland or VC++ )

-Flab

On Thu, 19 Aug 2004 11:42:50 -0400, Darren Dale wrote:

I love the language. I love the community. My only complaint is that
Python for Windows is built with Visual Studio.

It is too difficult to build python, or a module, from source. This is
what open source is all about, isnt it? I even have a copy of visual
studio, and I still cant build modules from source, because my academic
copy is version 7. As a scientist funded by the NSF, I feel compelled to
do all my work using free software (I feel compelled to use free
software, regardless). And I feel compelled to contribute to the
scientific capabilities of my favorite programming language. But this
compiler issue is a big (and seemingly unnecessary) impediment. Will the
BDFL ever split with Visual Studio?

[510046470588-0001]

flab ba <fl**@large.net> writes:

with the free Visual C++ Toolkit. Instructions are here:

all humbug. Visual C++ is nowhere near free, it's all proprietary.

Klaus Schilling

[Darren Dale]

Tim Roberts wrote:

Darren Dale <dd**@cornell.edu> wrote:

.... As a scientist funded by the NSF, I feel compelled to
do all my work using free software (I feel compelled to use free
software, regardless).

Then what on Earth are you doing with Windows?

I am working on switching to Linux. I cant commit until I graduate in 6
months.

[Darren Dale]

Tim Peters wrote:

[Darren Dale[

...
Will the BDFL ever split with Visual Studio?

We should be clear here that this isn't Guido's decision. What you
get on Windows is what you get on all other platforms in this respect:
you get what volunteers show up to produce, year after year after
year. So you get a fine Cygwin port from Jason Tishler, seemingly
toiling all alone, and you get contributions from at least four
developers who do use Visual Studio.

I meant no disrespect to the developers.

I don't think that's an accident. Most open source jockeys who use
Windows do so because it's needed for their day job, and sticking with
an MS compiler is widely perceived in pointy-hair boss-land as the
safest course on Windows. And it is a first-class IDE, so there's no
pragmatic reason to wrestle with yet another system when the day job
ends. It takes real sweat to get comfortable with any C development
tool chain, and it takes years to become familiar wth each one's
maddening quirks.

I expect that's why Guido still uses Visual Studio when he's running
on Windows (and know it's why I do), but he actually hasn't had
anything to do with the Windows Python releases for years. Things
Will Change when long-term volunteers show up and change them.

This comes back to the heart of the matter. How do you get volunteers
who dont have access to VS to get involved with Python development? I
think the suggestions here were right on, give Python the ability to
support MinGW out of the box. I thought that a compiler could even be
included in a version of the Windows distribution, but maybe that is
taking it too far.

[Paul Boddie]

Tim Peters <ti********@gmail.com> wrote in message news:<ma**************************************@pyt hon.org>...

So you get a fine Cygwin port from Jason Tishler,

[...]

Yes, it certainly is a great port! I'm rarely using the native Python
under Windows, but then Cygwin is an island of sanity in that
environment.

Paul

[Darren Dale]

I'm going to be out of touch for a few days... sorry to leave this while
its still being discussed.

[Graham Fawcett]

Greg Ewing <gr**@cosc.canterbury.ac.nz> wrote in message news:<2o************@uni-berlin.de>...

David Fraser wrote:

I agree. I don't mind it being built with Visual Studio, but out of the
box mingw compatibility would be cool...

As a step towards this, it would be useful if it were
distributed with the libpythonXX.a that mingw requires
already built. Then it would just be a matter of giving
the appropriate flag to setup.py when compiling a module.

+1! Building libpythonXX.a isn't tremendously hard, but it's a pain.
Given the simplicity of mingw's installation (and distutils'
familiarity with it) this would definitely simplify extension building
on win32.

-- Graham

[Tim Peters]

[Darren Dale]
....

Will the BDFL ever split with Visual Studio?

[Tim Peters] We should be clear here that this isn't Guido's decision. What you
get on Windows is what you get on all other platforms in this respect:
you get what volunteers show up to produce, year after year after
year. So you get a fine Cygwin port from Jason Tishler, seemingly
toiling all alone, and you get contributions from at least four
developers who do use Visual Studio.

[Darren] I meant no disrespect to the developers.
Didn't think you did. I'm just saying (a) the BDFL is irrelevant to
this particular issue; and, (b) you get what other people give. If
nobody with a long-term commitment to a specific Visual Studio
alternative appears, then #b rules.
...
This comes back to the heart of the matter. How do you get volunteers
who dont have access to VS to get involved with Python development?
Very few Python contributors have access to VS, but it doesn't matter
since most aren't running on Windows either. Even on Windows, VS is
usually irrelevant to whether somene can pitch in on reviewing bugs
and patches, improving the standard libraries, improving the docs,
helping on the newsgroup and mailing lists, keeping python.org
healthy, etc. I think it's more of a cultural thing, that Windows
users typically have a lower contribution rate than users on other
platforms (whether it's C code or anything else).

I mentioned Cygwin before, and you can certainly develop C extension
modules, for Python, on Windows, using that. Other responders have
their own favored VS alternatives. "A problem" is that there's more
than one VS alternative! That fragments the relatively-small-anyway
community of people who need a VS alternative on Windows.
I think the suggestions here were right on, give Python the ability to
support MinGW out of the box.
That's a wish. If it's to be granted, someone has to volunteer to do
the work initially, and keep it working as the years go by. Don't
expect that one of the current contributors will do so (they're
swamped already). IOW, it's not a matter of convincing someone it's a
good idea, it's a matter of someone volunteering to do actual, real
work.
I thought that a compiler could even be included in a version of the Windows
distribution, but maybe that is taking it too far.

That one won't happen -- most Windows Python users don't even know C,
and download size is still an issue for many. Even people who want to
work on core Python development on Windows using VS need to work from
a source tarball instead, or from a CVS checkout.

[Istvan Albert]

Ralf Schmitt wrote:

You can build modules using msys/mingw. Instructions can be found at
http://sebsauvage.net/python/mingw.html

works out great! I didn't even need to do step 3 (tweaking distutils).

thanks for the pointer.

Istvan.

[Jeff Shannon]

51***************@t-online.de wrote:

flab ba <fl**@large.net> writes:

with the free Visual C++ Toolkit. Instructions are here:

all humbug. Visual C++ is nowhere near free, it's all proprietary.

That's free-as-in-beer, not Free-as-in-speech.

It's a shame that, at least in English, the most natural word to use for
each of these two different concepts just happens to be the same word.
But such is the case. (I don't think it's practical to try to convince
everyone, worldwide, to refer to it as 'gratis' and 'liberte'...) And
given that it *is* the case, it would be much more pleasant if people
could use the word for both of its meanings without being criticized by
people who are philosophically devoted to only one of those meanings.

Jeff Shannon
Technician/Programmer
Credit International

[Tim Daneliuk]

Istvan Albert wrote:

Darren Dale wrote:

I love the language. I love the community. My only complaint is that
Python for Windows is built with Visual Studio.

It is too difficult to build python, or a module, from source.

In all fairness this is more the problem with Microsoft than
python. If they had a free fully-featured compiler then Python
would be compiled with that.

They do. MSC/C++ is now available at NO cost:

http://msdn.microsoft.com/visualc/vctoolkit2003/
----------------------------------------------------------------------------
Tim Daneliuk tu****@tundraware.com
PGP Key: http://www.tundraware.com/PGP/

[510046470588-0001]

Tim Daneliuk <tu****@tundraware.com> writes:

Istvan Albert wrote:

In all fairness this is more the problem with Microsoft than
python. If they had a free fully-featured compiler then Python
would be compiled with that.

They do. MSC/C++ is now available at NO cost:

no cost is not the same as free

Klaus Schilling

[Miklós]

"Jeff Shannon" <je**@ccvcorp.com> wrote in message
news:10*************@corp.supernews.com...

51***************@t-online.de wrote:

flab ba <fl**@large.net> writes:

all humbug. Visual C++ is nowhere near free, it's all proprietary.
That's free-as-in-beer, not Free-as-in-speech.

It's a shame that, at least in English, the most natural word to use for
each of these two different concepts just happens to be the same word.
But such is the case. (I don't think it's practical to try to convince
everyone, worldwide, to refer to it as 'gratis' and 'liberte'...) And
given that it *is* the case, it would be much more pleasant if people
could use the word for both of its meanings without being criticized by
people who are philosophically devoted to only one of those meanings.

It makes me smile that you keep getting into such semantic troubles unless
you express yourself in such a roundabout way.
I think it would be a really wise thing to always use the word 'gratis' for
'free-as-in-beer'.

Btw, my native language (Hungarian) avoids another serious semantic
booby-trap in English, with the ambigous word "love"... But at least in
c.l.p.
this rarely makes confusion. ;)

Miklós

Jeff Shannon
Technician/Programmer
Credit International

[Andrea Griffini]

On 21 Aug 2004 08:53:59 +0200, 51***************@t-online.de wrote:

They do. MSC/C++ is now available at NO cost:

no cost is not the same as free

Do you mean that there are limitations about legal use of
VC toolkit 2003 for building a python interpreter or that
you actually need to see the source code of the C compiler
to build python ?

Andrea

[Tim Daneliuk]

51***************@t-online.de wrote:

Tim Daneliuk <tu****@tundraware.com> writes:

Istvan Albert wrote:

In all fairness this is more the problem with Microsoft than
python. If they had a free fully-featured compiler then Python
would be compiled with that.

They do. MSC/C++ is now available at NO cost:

no cost is not the same as free

Klaus Schilling

<Goes Off The Reservation For A Moment>

"No Cost" is _exactly_ the same thing as "Free". It is not the same
thing as "Open Source".

The debate is foolish in any case. If I use an GPLed compiler, even with
the Lesser License, I have constraints placed upon what I may or may
not do with the derivative work. If I use a commercial compiler, I do
not have access to the source code _for the compiler_, but (usually)
there are no constraints placed upon what I may do with the derivative
work.

This whole mentality of "it must be 'free' or it's bad" is very silly
and at odds with how the world actually operates (aka Reality). I use
both freely available open source tools and commercial tools (that I've
paid for and licensed legitimately). Each has a place. One is not
inherently better than another.

The "freeness" of a particular product is only one of a number of
dimensions I examine when making tool choices for myself or my clients.
"Open Source" is often irrelevant to people - how many people actually
want to examine and modify the guts of compiler? Far more important than
the cost of acquistion is the _cost of ownership_. This is influenced
by a lot of things:

1) Training
2) Maintenance
3) Stability/Quality
4) Documentation
5) 3rd-Party support

IOW, I couldn't care less if something is "free", "freely available",
"open source", "closed source", or "commercial" software. I care about
whether it solves the problem at hand in a time- and cost-effective manner.

Unfortunately, Stallman and his ilk - for all their many contributions to
our field - have polluted the discussion with their hare-brained political
notions, naive ideas about intellectual property, and incessant whining
that everyone _else_ should "share" they way they define the term. I tire
of it as you may be able to tell from this short rant ...

Pax ...

</Back On The Reservation>

--
----------------------------------------------------------------------------
Tim Daneliuk tu****@tundraware.com
PGP Key: http://www.tundraware.com/PGP/

[Christophe Cavalaria]

Tim Daneliuk wrote:

51***************@t-online.de wrote:

Tim Daneliuk <tu****@tundraware.com> writes:

Istvan Albert wrote:

In all fairness this is more the problem with Microsoft than
python. If they had a free fully-featured compiler then Python
would be compiled with that.
They do. MSC/C++ is now available at NO cost:

no cost is not the same as free

Klaus Schilling

<Goes Off The Reservation For A Moment>

"No Cost" is _exactly_ the same thing as "Free". It is not the same
thing as "Open Source".

The debate is foolish in any case. If I use an GPLed compiler, even with
the Lesser License, I have constraints placed upon what I may or may
not do with the derivative work. If I use a commercial compiler, I do
not have access to the source code _for the compiler_, but (usually)
there are no constraints placed upon what I may do with the derivative
work.

This is wrong on so many levels :
- gcc is GPL software and you don't have to GPL the source code of the
programs you compile with it. Doing so would place a restriction on the
user of the software which is exactly what the GPL is trying to prevent.
Using gcc to compile source code isn't creating a derivative work of gcc !
- if you modify the gcc source code and thus create a derivative work, you
don't have to distribute the changes, unless you distribute the new gcc
version.
- with a commercial closed source compiler, you can't do any derivative of
the compiler at all and thus you have less freedom than with a GPL
compiler.

If you can't see the difference between using a software and creating a
derivative work of that software ...

[Tim Daneliuk]

Christophe Cavalaria wrote:

Tim Daneliuk wrote:

51***************@t-online.de wrote:

Tim Daneliuk <tu****@tundraware.com> writes:

Istvan Albert wrote:
>In all fairness this is more the problem with Microsoft than
>python. If they had a free fully-featured compiler then Python
>would be compiled with that.
They do. MSC/C++ is now available at NO cost:

no cost is not the same as free

Klaus Schilling

<Goes Off The Reservation For A Moment>

"No Cost" is _exactly_ the same thing as "Free". It is not the same
thing as "Open Source".

The debate is foolish in any case. If I use an GPLed compiler, even with
the Lesser License, I have constraints placed upon what I may or may
not do with the derivative work. If I use a commercial compiler, I do
not have access to the source code _for the compiler_, but (usually)
there are no constraints placed upon what I may do with the derivative
work.

This is wrong on so many levels :
- gcc is GPL software and you don't have to GPL the source code of the
programs you compile with it. Doing so would place a restriction on the
user of the software which is exactly what the GPL is trying to prevent.
Using gcc to compile source code isn't creating a derivative work of gcc !
- if you modify the gcc source code and thus create a derivative work, you
don't have to distribute the changes, unless you distribute the new gcc
version.
- with a commercial closed source compiler, you can't do any derivative of
the compiler at all and thus you have less freedom than with a GPL
compiler.

If you can't see the difference between using a software and creating a
derivative work of that software ...

It is "derivative" in the sense that the final binary may either contain
and/or depend upon library support shipped with the gcc compiler chain.
IIRC (and this may have changed - I have not looked at it in some time),
even the Lesser GPL places some constraints about what you _must_ distribute
(or be willing to provide) when you use their libs to produce a shipped product.
Moreover, for a long time (and this too may have changed), the corporate
lawyers I had checking the GPL did not like it because it was (legally)
muddy.

The only sense in which you have "less freedom" with a commercial product
is that you cannot build works that derive directly from the compiler/library
source code. So what? In most real world commercial applications, this is
a non-issue. Note that I was clear that I use _both_ OSS and Commercial products.
My rant is directed at people who thing Proprietary=Evil and OSS=Good which is
a nonsensical position.

--
----------------------------------------------------------------------------
Tim Daneliuk tu****@tundraware.com
PGP Key: http://www.tundraware.com/PGP/

[Robert Kern]

Tim Daneliuk wrote:

[snip]

It is "derivative" in the sense that the final binary may either contain
and/or depend upon library support shipped with the gcc compiler chain.
Yes, the final binary *may* depend on any number of libraries either
distributed with gcc or completely independent from gcc. The license of
those libraries have an effect on your program. The license of gcc does
not. gcc does not have to use glibc as the standard C library. For
example, the cygwin distribution of gcc uses their own newlib
(GPL+exception, I believe) and mingw uses Microsoft's MSVCRT. gcc can
also target the native libc on other systems. Or, if you provide your
own C runtime or do not need one, then there are no license problems.

I repeat, it is the license of the libraries that affects your program,
not the license of gcc.
IIRC (and this may have changed - I have not looked at it in some time),
even the Lesser GPL places some constraints about what you _must_
distribute
(or be willing to provide) when you use their libs to produce a shipped
product.

So can the licenses, proprietary or otherwise, of any other library any
compiler might link to.

--
Robert Kern
rk***@ucsd.edu

"In the fields of hell where the grass grows high
Are the graves of dreams allowed to die."
-- Richard Harter

[Bengt Richter]

On Fri, 20 Aug 2004 15:19:01 -0400, Tim Peters <ti********@gmail.com> wrote:

[Darren Dale]
...

Will the BDFL ever split with Visual Studio?
[Tim Peters] We should be clear here that this isn't Guido's decision. What you
get on Windows is what you get on all other platforms in this respect:
you get what volunteers show up to produce, year after year after
year. So you get a fine Cygwin port from Jason Tishler, seemingly
toiling all alone, and you get contributions from at least four
developers who do use Visual Studio.

[Darren]

I meant no disrespect to the developers.

Didn't think you did. I'm just saying (a) the BDFL is irrelevant to
this particular issue; and, (b) you get what other people give. If
nobody with a long-term commitment to a specific Visual Studio
alternative appears, then #b rules.

...
This comes back to the heart of the matter. How do you get volunteers
who dont have access to VS to get involved with Python development?

Very few Python contributors have access to VS, but it doesn't matter
since most aren't running on Windows either. Even on Windows, VS is
usually irrelevant to whether somene can pitch in on reviewing bugs
and patches, improving the standard libraries, improving the docs,
helping on the newsgroup and mailing lists, keeping python.org
healthy, etc. I think it's more of a cultural thing, that Windows
users typically have a lower contribution rate than users on other
platforms (whether it's C code or anything else).

I mentioned Cygwin before, and you can certainly develop C extension
modules, for Python, on Windows, using that. Other responders have
their own favored VS alternatives. "A problem" is that there's more
than one VS alternative! That fragments the relatively-small-anyway
community of people who need a VS alternative on Windows.

I think the suggestions here were right on, give Python the ability to
support MinGW out of the box.

That's a wish. If it's to be granted, someone has to volunteer to do
the work initially, and keep it working as the years go by. Don't
expect that one of the current contributors will do so (they're
swamped already). IOW, it's not a matter of convincing someone it's a
good idea, it's a matter of someone volunteering to do actual, real
work.

I thought that a compiler could even be included in a version of the Windows
distribution, but maybe that is taking it too far.

That one won't happen -- most Windows Python users don't even know C,
and download size is still an issue for many. Even people who want to
work on core Python development on Windows using VS need to work from
a source tarball instead, or from a CVS checkout.

Has anyone considered treating a current binary windows cpython distro like 2.3 as
a bootstrap, using a python script to control (e.g. via os and urllib etc) all the downloading
and md5/pgp-sig checking and building necessary to create an msys/MinGW installation
(as needed if not present) and then a python built from sources purely using msys/MinGW,
with end result being a python installation ready to be used in parallel, or to be switched
to as default?

It might take hours to download and crunch, and it might need to be re-startable
and be based on an evolving checkpointable config file of preferences etc, but why not?

If someone then wanted to make a script repackaging the result as a binary installation,
that would be handy too, and IWT some official versions of everything would wind up on python.org
after a while.

IMO a python script that created the whole thing from sources (well, ok, not including bootstrapping
msys/MingGW totally from sources ;-) would be a useful DOCUMENT as well as a tool. IOW, spreading
bot-knowledge can distribute the knowledge necessary to distributing the volunteer workload of
maintaining and improving the thing. I'm thinking simple text UI control as necessary.

Such a migration bootstrap script seems to me like it would have more robust survival prospects than
an equivalent-end-result prebuilt binary distro made ad hoc by hand and contributed.

Seems like someone must have thought of this before. I guess pieces exist as .bat or .cmd files,
but I'd like to see the whole thing wrapped in a single flexible python script.

Regards,
Bengt Richter

[David Fraser]

Andrea Griffini wrote:

On 21 Aug 2004 08:53:59 +0200, 51***************@t-online.de wrote:

They do. MSC/C++ is now available at NO cost:

no cost is not the same as free

Do you mean that there are limitations about legal use of
VC toolkit 2003 for building a python interpreter or that
you actually need to see the source code of the C compiler
to build python ?

There are other benefits to open source compilers - in gcc's case, a
specific advantage is that it can cross-compile from other operating
systems. In certain circumstances that can be a big advantage

David