k-mack
commented
6 years ago This would be a real nice-to-have. I hope you won't mind me chiming in on those open questions.
Since Swift is a language and a compiler (well, they share the same name), it seems that doing this for C++ will be more complex than how it is done in SwiftSourceCompatibility. It would seem there would be a layer between the compiler and the language version to help make the decision about what dialect option should be used. For example, there would be some type of construct, say GccVersionLanguageSupport, that would verify the source compatibility with a specific version of the compiler. This could be queried with a VersionNumber and a CppSourceCompatibility to return the dialect option that should be used when invoking the compiler.
Thinking out loud, it may look something like below. There would need to be some interfaces to bridge the API between the GCC, Clang, and MSVC implementations.
public enum CppSourceCompatibility {
Cpp98, Cpp98Extended, // "Extended" meaning use the compiler's language extensions
Cpp03, Cpp03Extended, // Users should understand that extensions are compiler-dependent
Cpp11, Cpp11Extended,
Cpp14, Cpp14Extended,
Cpp17, Cpp17Extended
}
public class GccVersionLanguageSupport {
public static String getLanguageStandardOption(VersionNumber version, CppSourceCompatibility dialect) {
// Modeled after gcc documentation; clang and msvc should be just as straightforward
switch (dialect) {
case Cpp17: Cpp17Extended:
// Still waiting for gcc to support "-std=c++17" and deprecate "-std=c++1z"
if (version.getMajor() >= 5) {
return dialect == Cpp17 ? "-std=c++1z" : "-std=gnu++1z"
}
break;
case Cpp14: Cpp14Extended:
// gcc 5 and later is c++14 complete
// gcc 4.8-4.9 has experimental support for c++14 (compatibility not guaranteed between versions so ABI is also not guaranteed)
if (version.getMajor() >= 5) {
return dialect == Cpp14 ? "-std=c++14" : "-std=gnu++14"
} else if (version.getMajor() >= 4 && (version.getMinor() == 8 || version.getMinor() == 9)) {
return dialect == Cpp14 ? "-std=c++1y" : "-std=gnu++1y"
}
break;
// rest of cases...
}
return null; // i.e., the provided version of the compiler does not support the provided dialect
}
}Clang uses the same "-std=..." options, so the logic would be similar. With respect to MSVC extensions, I think the logic above would only need to decide whether or not to use "/Za," "/Ze," or "/Zc" (if using VS 2017). It would be challenging to model each compiler's specific language standard extension individually as each compiler and version may offer different extensions. It may suffice to just support the user in adding additional arguments to the compiler for further customization of the dialect.
The compiler-specific, dialect-related preprocessor macros could be queried in a similar fashion. I think the main ones would be __STDC__, __STDCVERSION__, and \_cplusplus. Although, MSVC isn't very helpful since it hasn't kept up-to-date with the __cplusplus macro value.
lacasseio
ice1000
adammurdoch
akemimadoka
eaaltonen
As with the Swift language, source compatibility should also be supported for C++ language.
Expected Behaviors
Users can specify the C++ language (C++98, C++03, C++11, C++14, C++17, etc.) on the component to compile.
Open Questions
gnu++14or Microsoft language extensions)? Especially when the component can be built for different platforms.Test Cases