Hi
could you provide more details on this? I thought the Vanilla/Strawberry Perls were bundled with a gcc compiler. Is this a requirement of Strawberry perl or of the grant?
thanks, j
Update:
It's the date thing, right? | [reply] |
No, it is not part of the grant to do any additional work to adapt to changes introduced by commercial compilers that may have broken existing code.
Vanilla/Strawberry are built with gcc, and while some people may feel it is important to do the work needed to handle changes in commercial compilers, I don't personally feel it is the responsibility of the TPF to be funding compatability with non-open-source compilers, particularly where the blame for the code not working lies with those commercial compilers.
So while obviously you shouldn't be introducing any NEW bugs that might break existing working scenarios, fixing problems caused by commercial compiler vendors will not be part of the grant, or at least part of THIS grant. The grant committee may feel it is worth seperately funding this work, but I'd prefer to deal with seperate problems seperately.
In addition, and as an aside, Windows Vista is incompatible with nmake, and there is no obvious upgrade path for name, seeing as we have been using a very very old legacy build of nmake this entire time.
So from Vista onwards, I would expect that all Perl distributions will need to transition away from nmake to something like dmake.
| [reply] |
Work has already been done by Gisle Aas of ActiveState to allow XS modules to be compiled with either the MinGW gcc or Visual C++, regardless of the compiler that Win32 Perl was built with (see Perl change #27555 for details). I'm pretty sure that Perl has been able to be built with either dmake or nmake with Visual C++ for some time now. It would be nice, however, and I'm sure you would agree, to allow users their choice of compilers on whatever operating system they choose. I would hate to see this project be a step backwards in Perl support on Win32.
With Windows Vista, all indications are that support for the free nmake will go away. The nmakes provided with recent Visual Studio's or .NET SDKs will still work. In exchange for losing free nmake support, however, we will have a usable and programmable shell that may be able to be used to provide a sane Configure script. So, I see Vista as a great new opportunity and challenge for porting Perl rather than an obstacle.
As far as working with commercial compilers, Perl is everywhere and should be able to be compiled with any sane C compiler, commercial or not, just as it is supported on almost every free and commercial operating systems. Whether the C compiler is commercial or not should be irrelevant. Support for Visual C++ 8.0 will be provided. Its simply a matter of time. I consider it to be a major bug that it isn't supported at this time. This is why I see this support as important for this project.
| [reply] |