> I'm currently doing a native mingw32 port of Python, and I've hit the > ugly "initializer is not a constant" problem mentioned in the FAQ. Hmm, > looks like I have three options: > > 1 Fix the Python sources in the Object/ directory and initalize the > structs in a seperate init_objects function > 2 compile Python with a C++ compiler > 3 fix the mingw32 compiler > > When trying option 2, I recognized that a lot of Python's source is not > valid ANSI C++. There are even variable names like "class" and "new". > There are of course less obvious issues when trying to make the source > compile as C++, in particular a lot more casts are needed. If it's just > that Python is supposed to compile as C++ but it hasn't been tested for > a while, I could do the necessary fixes and submit a patch. But if > that's a new idea, I don't know if fixing it now makes sense. > > Because I plan to submit the required changes as a patch when the port > is ready, I'd like to know if you'd accept a patch for option #1. Sounds to me like the Mingw32 compiler is not ANSI compatible. I don't want to have to change the source to accommodate a broken compiler that a very small minority of users want to use. So I am against #1. We never said that our .c files would be valid C++ (.h files is a different story) so I think #2 is not an option. I vote for #3 -- if enough software can't compiled with mingw32 the compiler will be fixed, as it should, and I'm happy to help encourage this. --Guido van Rossum (home page: http://www.python.org/~guido/)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4