Open mathstuf opened 10 years ago
My version detection works via D's VERSION "special token", which is an integer in the form XYYY, where X is the major version and YYY the minor. Unless the devs decide to change that and break all code that checks versions, or add a separate way to get the patch version, it will have to be ignored.
With regard to the minor version, CMake has a programmatically-enforced policy on leading zeros in version numbers. Even if the compiler version detection gives version 2.064 (which it does, IIRC), CMake thinks (knows?) that leading zeros don't change what the version semantically is, and chops them off. I don't think changing CMake's behavior here to work with D's (IMO wrong-headed) version number styling is desirable.
Ah, you're probably using the math
command to get the versions then? Yeah, that'd strip the zero. Other than that (e.g., string(SUBSTRING)
), CMake probably doesn't actually care. Probably better since the zero would make it be treated as octal otherwise when substituted into code.
Ah, you're probably using the
math
command to get the versions then? Yeah, that'd strip the zero.
Not directly. Modules/CMakeDCompilerId.d.in
is responsible for the actual compiler version detection, and it will yield a version in the form "2.064".
Upon investigation, I see that line 387 in Modules/CMakeDetermineCompilerId.cmake
regexes off the leading zeros in the components of compiler versions.
I think the best course of action is to convince the D community that leading zeros are useless. From what I see on the mailing list, Andrew Edwards (the release manager in recent releases) initially intended to release a 2.65 instead of a 2.065. Only one person raised any (mild) concern, in the form of appealing to DMD's historical precedent, and the leading zero was kept.
I'm seeing the following output:
when the actual version is
2.064.2
. The patch version can (probably) be ignored, but the minor version should probably be padded to 3 digits.