The PSC proposes that we no longer support VC11.0 and earlier.
ie "Microsoft Visual C++ 2013 Express x86 (VC12.0)" is the earliest *MVSC*
version that we support, as this is the first version that supports C99.
This doesn't affect any other compiler or toolchain on Win32 or any other
platform - ie
* We still intend to support Cygwin, MinGW and MinGW64
* gcc 3.1 should be fine to build Perl, but no-one tests gcc that old
* We believe Perl builds with all OS vendor compilers (still in support)
Also, VC12.0 is capable of *targeting* XP and Windows Server 2003 [1]
but the build host requirement is Windows 7/Windows Server 2012 [2]
meaning that decisions about what is the earliest Windows version(s) we
support (and hence minimum APIs we can rely on) can be an independent
decision.
(ie please discuss that in a separate thread)
We are suggesting this change as it permits us to use some C99 features in
the Perl source code. C99 - that's 22 years ago, that should be fine, right?
C11 declared some parts of C99 optional, because some platforms *still*
didn't support them (or they were a bad idea). So we need to tread
carefully.
Vendor support is patchy. It seems useful to split C99 three ways
1) Language syntax changes, such as mixed variable declarations and code
2) Changes to header files (that require no extra runtime library support)
3) New functions/functionality in the C standard library
Testing shows that only the first can be relied upon, even for features that
one would think were easy to implement. Also, our public headers need to
remain compatible with deployed C++ compilers, which restricts some syntax.
This doesn't give us Carte Blanche to add C99-isms everywhere. For example,
VMS only got <stdint.h> *last year* (which I don't think would require C
library changes), and the %z format specification (which feels like a 1 line
addition to an existing switch statement). It's still fine to probe for C99
(and later) functionality and take advantage of it if found, as long as we
can still build without it.
What we've tested is currently at https://github.com/Perl/perl5/wiki/C99
but this needs to be moved into a Pod file.
The PSC asks
1) Are there any mistakes/problems in the above?
2) What is a sensible place to document build requirements?
3) For a volunteer to handle updating the documentation
and proposes that it's not permitted to use C99-isms until the documentation
is done. :-)
1: https://docs.microsoft.com/en-us/visualstudio/productinfo/vs2013-compatibility-vs
2: https://docs.microsoft.com/en-us/visualstudio/productinfo/vs2013-sysrequirements-vs
ie "Microsoft Visual C++ 2013 Express x86 (VC12.0)" is the earliest *MVSC*
version that we support, as this is the first version that supports C99.
This doesn't affect any other compiler or toolchain on Win32 or any other
platform - ie
* We still intend to support Cygwin, MinGW and MinGW64
* gcc 3.1 should be fine to build Perl, but no-one tests gcc that old
* We believe Perl builds with all OS vendor compilers (still in support)
Also, VC12.0 is capable of *targeting* XP and Windows Server 2003 [1]
but the build host requirement is Windows 7/Windows Server 2012 [2]
meaning that decisions about what is the earliest Windows version(s) we
support (and hence minimum APIs we can rely on) can be an independent
decision.
(ie please discuss that in a separate thread)
We are suggesting this change as it permits us to use some C99 features in
the Perl source code. C99 - that's 22 years ago, that should be fine, right?
C11 declared some parts of C99 optional, because some platforms *still*
didn't support them (or they were a bad idea). So we need to tread
carefully.
Vendor support is patchy. It seems useful to split C99 three ways
1) Language syntax changes, such as mixed variable declarations and code
2) Changes to header files (that require no extra runtime library support)
3) New functions/functionality in the C standard library
Testing shows that only the first can be relied upon, even for features that
one would think were easy to implement. Also, our public headers need to
remain compatible with deployed C++ compilers, which restricts some syntax.
This doesn't give us Carte Blanche to add C99-isms everywhere. For example,
VMS only got <stdint.h> *last year* (which I don't think would require C
library changes), and the %z format specification (which feels like a 1 line
addition to an existing switch statement). It's still fine to probe for C99
(and later) functionality and take advantage of it if found, as long as we
can still build without it.
What we've tested is currently at https://github.com/Perl/perl5/wiki/C99
but this needs to be moved into a Pod file.
The PSC asks
1) Are there any mistakes/problems in the above?
2) What is a sensible place to document build requirements?
3) For a volunteer to handle updating the documentation
and proposes that it's not permitted to use C99-isms until the documentation
is done. :-)
1: https://docs.microsoft.com/en-us/visualstudio/productinfo/vs2013-compatibility-vs
2: https://docs.microsoft.com/en-us/visualstudio/productinfo/vs2013-sysrequirements-vs