Re: [cmake-developers] C++11 and target_compiler_feature proposal
Steve, On 10/25/2013 09:11 AM, Brad King wrote: Yes, I think that makes sense. Looking at the documentation generated in 'next' I see this list of commands: target_compile_definitions target_compile_options target_compiler_features I think the new command should be called target_compile_features for consistency with the other compiler settings commands. -Brad -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] C++11 and target_compiler_feature proposal
Brad King wrote: Steve, On 10/25/2013 09:11 AM, Brad King wrote: Yes, I think that makes sense. Looking at the documentation generated in 'next' I see this list of commands: target_compile_definitions target_compile_options target_compiler_features I think the new command should be called target_compile_features for consistency with the other compiler settings commands. Makes sense to me. COMPILER_FEATURES - COMPILE_FEATURES INTERFACE_COMPILER_FEATURES - INTERFACE_COMPILE_FEATURES too? Thanks, Steve. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] C++11 and target_compiler_feature proposal
On 10/30/2013 10:39 AM, Stephen Kelly wrote: Makes sense to me. COMPILER_FEATURES - COMPILE_FEATURES INTERFACE_COMPILER_FEATURES - INTERFACE_COMPILE_FEATURES Yes, matching COMPILE_OPTIONS and COMPILE_DEFINITIONS. Thanks, -Brad -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] C++11 and target_compiler_feature proposal
Brad King wrote: On 10/30/2013 10:39 AM, Stephen Kelly wrote: Makes sense to me. COMPILER_FEATURES - COMPILE_FEATURES INTERFACE_COMPILER_FEATURES - INTERFACE_COMPILE_FEATURES Yes, matching COMPILE_OPTIONS and COMPILE_DEFINITIONS. Right, done now. Thanks, Steve. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] C++11 and target_compiler_feature proposal
On 10/25/2013 09:02 AM, Stephen Kelly wrote: For 'broken' things like cxx_initializer_lists and cxx_variadic_templates, I recommend that we enable the feature if the compiler vendor says it is available. Yes, I think that makes sense. The problem with trying to report broken ourselves is that only the project knows if the feature is too broken for it. Developers using these bleeding-edge language features are used to conditional workarounds in their code anyway. -Brad -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] C++11 and target_compiler_feature proposal
On 10/24/2013 10:23 AM, Stephen Kelly wrote: Also when you run the compiler you need to capture all stdout/stderr so that it never leaks through to the user-visible cmake configuration output. The RunCMake.* tests that failed last night were mostly due to compilers writing to stderr even when nothing is wrong and therefore messing with the expected output matching. Should be all fixed now. Your patch did: +RESULT_VARIABLE _result +OUTPUT_VARIABLE _output but RESULT_VARIABLE is for the return code or administrative error message. You also need ERROR_VARIABLE _error to get stderr. Without this the tests still failed last night. -Brad -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] C++11 and target_compiler_feature proposal
Brad King wrote: On 10/23/2013 05:59 PM, Stephen Kelly wrote: CMAKE_CXX_COMPILER is always set to the proper full path these days, even in the IDE generators, so I wonder if we could actually run it against the header file to detect the features available for the current compiler instead of hard-coding a table in the platform information files. Then the checks would all be done in one place via the preprocessor and __has_feature if available. I've implemented this and merged it to next for dashboard testing. Please see the hythloth.kitware Linux64-gnu build entry on the dashboard for some documentation errors reported by sphinx-build. Also when you run the compiler you need to capture all stdout/stderr so that it never leaks through to the user-visible cmake configuration output. The RunCMake.* tests that failed last night were mostly due to compilers writing to stderr even when nothing is wrong and therefore messing with the expected output matching. Should be all fixed now. Thanks, Steve. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] C++11 and target_compiler_feature proposal
Brad King wrote: CMAKE_CXX_COMPILER is always set to the proper full path these days, even in the IDE generators, so I wonder if we could actually run it against the header file to detect the features available for the current compiler instead of hard-coding a table in the platform information files. Then the checks would all be done in one place via the preprocessor and __has_feature if available. I've implemented this and merged it to next for dashboard testing. I haven't yet looked into how to create docs for the new WriteCompilerDetectionHeader module. Thanks, Steve. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] C++11 and target_compiler_feature proposal
Brad King wrote:
On 10/21/2013 04:05 PM, Stephen Kelly wrote:
I'm still not sure that generating a header specific to the compiler (ID
and version) is a good idea.
[snip]
So, I think maybe it would make sense to list features separately, and if
someone does this:
I thought we had reached that conclusion before. See the bottom of
this message:
http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/6726/focus=7809
Anyway, we agree.
Further-on, you responded:
Why do you need to check features of a compiler not currently enabled?
write_compiler_detection_header(
FILE ${CMAKE_CURRENT_BINARY_DIR}/grantlee_compiler_detection.h
PREFIX Grantlee_
FEATURES cxx_final cxx_override
)
Yes, though it still needs the mandatory VERSION.
I thought the VERSION would be optional and would default to
CMAKE_MINIMUM_REQUIRED_VERSION:
http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/6726/focus=7812
the generated header would look something like this:
Yes.
Actually it appears this header will duplicate most of the compiler
feature
knowledge encoded in the CMake platform modules we discussed before. I
wonder if we can come up with a representation that can be used to
generate both.
Probably. However, that means that we either shouldn't use the clang
__has_feature() test that I implemented, or we'll have to duplicate all of
that information anyway.
Thanks,
Steve.
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] C++11 and target_compiler_feature proposal
On 10/22/2013 11:31 AM, Stephen Kelly wrote: Further-on, you responded: Why do you need to check features of a compiler not currently enabled? That was talking about the platform file tables, not the header. I thought the VERSION would be optional and would default to CMAKE_MINIMUM_REQUIRED_VERSION: http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/6726/focus=7812 Yes, okay. Actually it appears this header will duplicate most of the compiler feature knowledge encoded in the CMake platform modules we discussed before. I wonder if we can come up with a representation that can be used to generate both. Probably. However, that means that we either shouldn't use the clang __has_feature() test that I implemented, or we'll have to duplicate all of that information anyway. CMAKE_CXX_COMPILER is always set to the proper full path these days, even in the IDE generators, so I wonder if we could actually run it against the header file to detect the features available for the current compiler instead of hard-coding a table in the platform information files. Then the checks would all be done in one place via the preprocessor and __has_feature if available. -Brad -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] C++11 and target_compiler_feature proposal
On 10/22/2013 12:27 PM, Stephen Kelly wrote: Stephen Kelly wrote: I'll try to get a reviewable and first-feature-complete infrastructure branch together soon. Meanwhile, I've been continuing work on the target_compiler_features topic, which is for REQUIRED features. It's mostly feature complete now, but with a few things missing like adding -std flags for the correct compiler versions. It includes transitive requirement of compiler features, and a generator expression for testing whether a target has enabled the feature. It's also missing some unit tests etc. As this is orthogonal to an compilerdetection.h header, which is for optional features, I think I can polish this up and get it master soonish. Any comments? See my sibling response about implementing required feature lookup using the header. Otherwise, I'd like Eike to review your topic too. -Brad -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] C++11 and target_compiler_feature proposal
Stephen Kelly wrote:
I'll try to get a reviewable and first-feature-complete infrastructure
branch together soon.
I've pushed a first iteration of the target_compiler_features branch to my
clone.
For the language specification, I added a prefix to each feature. This
matches the feature tests of clang for standard features, and it is
extensible to extensions with gnuxx_typeof, msvc_sealed etc.
http://clang.llvm.org/docs/LanguageExtensions.html
So far, it only supports the REQUIRED signature of the command.
It will need to get a PUBLIC|PRIVATE specifier, so that the
INTERFACE_COMPILER_FEATURES property can be populated in PUBLIC mode. It
also needs to learn to process generator expressions and how to consume that
property.
Optional features with defines are not yet implemented. I was considering
renaming target_compiler_features to target_required_features and not using
the same command for optional features. Instead I think it might be a good
idea to have a separate command for optional features. Something like:
write_compiler_feature_file(
FILENAME ${CMAKE_CURRENT_BINARY_DIR}/grantlee_compiler_features.h
FEATURES cxx_static_assert gnuxx_typeof cxx_variadic_templates
)
install(FILES ${CMAKE_CURRENT_BINARY_DIR}/grantlee_compiler_features.h
DESTINATION include
)
which writes the file with appropriate content. I don't see any need to use
preprocessor macros for that instead of a file.
I also prototyped a simple way to test clang features as reportedly
supported by clang itself. This won't get us all of the way there with
clang, as some features (such as the gnu typeof extension) do not have
support via __has_extension.
Additionally, I changed my mind on the issue of whether to bump the dialect
to c++11 if the compiler supports the requested feature in c++98 mode. For
example, cxx_variadic_templates would be in CMAKE_CXX98_COMPILER_FEATURES
for GCC and clang, because both support variadic templates even when using
the -std=c++98 dialect. This will still warn, but that's ok, I think.
Note that adding -std=c++11 is almost, but not quite, entirely source
compatible.
For example, this will work with c++98, but errors with c++11:
#define add_prefix(suf) pre_suf
add_prefix(_end);
The feature can be extended for the C standard (89, 99, 11) features too as
well as extensions.
Any comments so far?
Thanks,
Steve.
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] C++11 and target_compiler_feature proposal
Hi Steve,
Thanks for working on this!
On 10/17/2013 10:28 AM, Stephen Kelly wrote:
For the language specification, I added a prefix to each feature. This
matches the feature tests of clang for standard features, and it is
extensible to extensions with gnuxx_typeof, msvc_sealed etc.
http://clang.llvm.org/docs/LanguageExtensions.html
Good idea.
So far, it only supports the REQUIRED signature of the command.
It will need to get a PUBLIC|PRIVATE specifier, so that the
INTERFACE_COMPILER_FEATURES property can be populated in PUBLIC mode. It
also needs to learn to process generator expressions and how to consume that
property.
Yes.
Optional features with defines are not yet implemented. I was considering
renaming target_compiler_features to target_required_features
I think target_compiler_features is a clearer name even if it only
supports required features. Please leave room in the signature for
future expansion to optional features just in case.
and not using the same command for optional features. Instead I think
it might be a good idea to have a separate command for optional features.
FWIW, I thought he optional features with macros was quite elegant.
Also that approach didn't require header generation, right? I have
no strong opinion on which approach is better, but here are some
comments.
What is an example use case for optional features? What if a header
file selects an available optional feature when included by a .cxx
in the package's libraries, but not when it is later included by an
application? Might that generate an ABI mismatch?
write_compiler_feature_file(
FILENAME ${CMAKE_CURRENT_BINARY_DIR}/grantlee_compiler_features.h
FEATURES cxx_static_assert gnuxx_typeof cxx_variadic_templates
)
IIUC this header will contain hard-coded preprocessor tests and present
the results in preprocessor symbols testable by the project. Shouldn't
it take some kind of namespace prefix for those names? Also this may
need the VERSION interface number previously discussed.
install(FILES ${CMAKE_CURRENT_BINARY_DIR}/grantlee_compiler_features.h
DESTINATION include
)
If the header is not in the public interface it need not be installed either.
which writes the file with appropriate content. I don't see any need to use
preprocessor macros for that instead of a file.
That will also simplify consuming an interface without CMake because no
magic addition of preprocessor definitions will be needed.
I also prototyped a simple way to test clang features as reportedly
supported by clang itself. This won't get us all of the way there with
clang, as some features (such as the gnu typeof extension) do not have
support via __has_extension.
Neat. I see no reason Modules/FeatureTests/clang_feature_tests.cxx
can't be just Modules/Compiler/clang_feature_tests.cxx. For those
features not covered by __has_extension we can list them explicitly.
You'll also have to deal with cases when CMAKE_CXX_COMPILER is not
set. It should always be set at this point but we need to fail with
a readable explanation if it is not.
Additionally, I changed my mind on the issue of whether to bump the dialect
to c++11 if the compiler supports the requested feature in c++98 mode. For
example, cxx_variadic_templates would be in CMAKE_CXX98_COMPILER_FEATURES
for GCC and clang, because both support variadic templates even when using
the -std=c++98 dialect. This will still warn, but that's ok, I think.
Note that adding -std=c++11 is almost, but not quite, entirely source
compatible.
Okay.
Any comments so far?
Should we memoize the language feature lists as std::set at the end of
cmGlobalGenerator::EnableLanguage to make lookup faster and avoid projects
corrupting the lists?
Thanks,
-Brad
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] C++11 and target_compiler_feature proposal
Brad King wrote:
Optional features with defines are not yet implemented. I was considering
renaming target_compiler_features to target_required_features
I think target_compiler_features is a clearer name even if it only
supports required features. Please leave room in the signature for
future expansion to optional features just in case.
Ok. When PUBLIC|PRIVATE is part of it, that will be easy even if I remove
REQUIRED.
and not using the same command for optional features. Instead I think
it might be a good idea to have a separate command for optional features.
FWIW, I thought he optional features with macros was quite elegant.
Also that approach didn't require header generation, right?
Correct.
I have
no strong opinion on which approach is better, but here are some
comments.
What is an example use case for optional features?
Adding a move constructor to a class. Many Qt classes have move constructors
and they are inline and bounded by a define.
Another: Define Foo_OVERRIDE to either 'override' or nothing, depending on
the using compiler capability.
What if a header
file selects an available optional feature when included by a .cxx
in the package's libraries, but not when it is later included by an
application? Might that generate an ABI mismatch?
As far as I know, no. Things like r-value references, variadic templates etc
would just be unavailable to the caller if not using a capable compiler.
Things like final and override are not encoded into the ABI afaik. At least
that seems to be the assumption Qt makes.
write_compiler_feature_file(
FILENAME ${CMAKE_CURRENT_BINARY_DIR}/grantlee_compiler_features.h
FEATURES cxx_static_assert gnuxx_typeof cxx_variadic_templates
)
IIUC this header will contain hard-coded preprocessor tests and present
the results in preprocessor symbols testable by the project. Shouldn't
it take some kind of namespace prefix for those names? Also this may
need the VERSION interface number previously discussed.
Oops, yes, you're right on both counts. I didn't re-read the previous thread
before writing the above.
install(FILES ${CMAKE_CURRENT_BINARY_DIR}/grantlee_compiler_features.h
DESTINATION include
)
If the header is not in the public interface it need not be installed
either.
If the intention is to define Grantlee_OVERRIDE to either 'override' or
nothing depending on the compiler capability, and to use classes using that
define in the interface, then it does have to be installed.
which writes the file with appropriate content. I don't see any need to
use preprocessor macros for that instead of a file.
That will also simplify consuming an interface without CMake because no
magic addition of preprocessor definitions will be needed.
Yes.
I also prototyped a simple way to test clang features as reportedly
supported by clang itself. This won't get us all of the way there with
clang, as some features (such as the gnu typeof extension) do not have
support via __has_extension.
Neat. I see no reason Modules/FeatureTests/clang_feature_tests.cxx
can't be just Modules/Compiler/clang_feature_tests.cxx. For those
features not covered by __has_extension we can list them explicitly.
You'll also have to deal with cases when CMAKE_CXX_COMPILER is not
set. It should always be set at this point but we need to fail with
a readable explanation if it is not.
Ok.
Any comments so far?
Should we memoize the language feature lists as std::set at the end of
cmGlobalGenerator::EnableLanguage to make lookup faster and avoid projects
corrupting the lists?
I'm not sure. We might not list a feature which a compiler has, either
because the compiler release is newer than the cmake release, or because the
compiler is unknown to us.
In that case, being able to use
list(APPEND CMAKE_CXX_COMPILER_FEATURES cxx_variadic_templates)
would be useful.
Thanks,
Steve.
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] C++11 and target_compiler_feature proposal
On 10/10/2013 08:07 PM, Stephen Kelly wrote: So, I think this is a two dimensional calculation. There is a standard axis and a extension axis for the compiler flag, for GCC and clang at least. Yes. if (NOT CMAKE_CXX_COMPILER_VERSION VERSION_LESS 4.7) set(CMAKE_CXX11_STANDARD_COMPILE_OPTION -std=c++11) set(CMAKE_CXX11_EXTENSION_COMPILE_OPTION -std=gnu++11) endif() Will this work for XL too? I wonder if we should always use the extension flag, unless otherwise specified with set(CMAKE_STRICT_CXX_STANDARD ON)? Because gnu++98 is the GCC default, someone could be using 'gnu template instantiation' in existing code, and then uses CMake to specify the need for variadic_templates, so we add -std=c++11 and boom - no more gnu extensions. As you point out the user would have to have modified the project anyway so at that point they can specify explicitly the default extensions they were using before. -Brad -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] C++11 and target_compiler_feature proposal
On 10/11/2013 02:16 AM, Rolf Eike Beer wrote: Brad, this is one of your dashboard machines. I currently can't find the mails where we discussed that. Can you please give Steven some information about this? Sorry, I have no idea to what dashboard machine, emails, feature, compiler, or problem you're referring. Can you be more specific please? The only mention of simulated compiler id recently has been the new support for Clang on windows simulating MSVC. -Brad -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] C++11 and target_compiler_feature proposal
Brad King wrote: On 10/10/2013 08:07 PM, Stephen Kelly wrote: So, I think this is a two dimensional calculation. There is a standard axis and a extension axis for the compiler flag, for GCC and clang at least. Yes. if (NOT CMAKE_CXX_COMPILER_VERSION VERSION_LESS 4.7) set(CMAKE_CXX11_STANDARD_COMPILE_OPTION -std=c++11) set(CMAKE_CXX11_EXTENSION_COMPILE_OPTION -std=gnu++11) endif() Will this work for XL too? I assume so. The only flag I'm aware of for XL is -qlanglvl=extended0x, and that is equivalent to -std=c++11 afaik. What are you referring to specifically? I wonder if we should always use the extension flag, unless otherwise specified with set(CMAKE_STRICT_CXX_STANDARD ON)? Because gnu++98 is the GCC default, someone could be using 'gnu template instantiation' in existing code, and then uses CMake to specify the need for variadic_templates, so we add -std=c++11 and boom - no more gnu extensions. As you point out the user would have to have modified the project anyway so at that point they can specify explicitly the default extensions they were using before. Hmm, this might be a sticking point. I'm in favor of sticking close to the defaults of the compiler. The user shouldn't have to tell CMake to use the extension if that is the default for the compiler anyway, just as a penalty for telling CMake about requiring variadic templates. Thanks, Steve. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] C++11 and target_compiler_feature proposal
On 10/11/2013 10:56 AM, Stephen Kelly wrote: I assume so. The only flag I'm aware of for XL is -qlanglvl=extended0x, and that is equivalent to -std=c++11 afaik. What are you referring to specifically? I was just touching back on the issue you originally raised about -qlanglvl=extended0x. I'm in favor of sticking close to the defaults of the compiler. The user shouldn't have to tell CMake to use the extension if that is the default for the compiler anyway, just as a penalty for telling CMake about requiring variadic templates. If it is a cross-platform project then it should not depend on a non-standard language feature without saying so. Once a project starts using the target_compiler_feature command then it should be aware of the implications. -Brad -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] C++11 and target_compiler_feature proposal
Am Freitag, 11. Oktober 2013, 09:19:46 schrieb Brad King: On 10/11/2013 02:16 AM, Rolf Eike Beer wrote: Brad, this is one of your dashboard machines. I currently can't find the mails where we discussed that. Can you please give Steven some information about this? Sorry, I have no idea to what dashboard machine, emails, feature, compiler, or problem you're referring. Can you be more specific please? The only mention of simulated compiler id recently has been the new support for Clang on windows simulating MSVC. There is one dashboard machine that uses a combined gcc+clang compiler. I remember having many problems when the tests error'ed out when the tests suddenly showed support for features not expected in some compiler version. If nothing comes right to your mind I'll dig further. Eike signature.asc Description: This is a digitally signed message part. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] C++11 and target_compiler_feature proposal
On 10/11/2013 01:22 PM, Rolf Eike Beer wrote: There is one dashboard machine that uses a combined gcc+clang compiler. I remember having many problems when the tests error'ed out when the tests suddenly showed support for features not expected in some compiler version. If nothing comes right to your mind I'll dig further. No, sorry. What does combined gcc+clang mean? -Brad -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] C++11 and target_compiler_feature proposal
Brad King wrote:
On 10/09/2013 10:44 AM, Stephen Kelly wrote:
if(NOT needs17 EQUAL -1)
set(standard 17)
elseif(NOT needs14 EQUAL -1)
set(standard 14)
elseif(NOT needs11 EQUAL -1)
set(standard 11)
endif()
# ...
set_property(TARGET ${TARGET_NAME} PROPERTY CXX_STANDARD ${standard})
This assumes a linear ordering among standards, which is true for the
actual standards, but may not be true for the compiler feature levels.
For example, the GNU compiler has a gnu variant branching off from
each standard level.
Right, it is not really linear. One of my dependencies might require some
extension feature like 'gnu_template_instantiation' feature, which we'd list
as being a -std=gnu++98 feature.
http://gcc.gnu.org/onlinedocs/gcc/Template-Instantiation.html#Template-Instantiation
Another dependency might require variadic_templates, which is -std=c++11.
So, our calculation should result in -std=gnu++11, assuming extensions are
either consistently available between standard version specifications or
subsumed by more-recent standards.
Are any other compilers as 'interesting' or have extensions like that?
Interestingly, clang supports rvalue references in c++98 mode as an
extension, but GCC does not:
http://clang.llvm.org/docs/LanguageExtensions.html
stephen@hal:~/dev/src/playground/cpp{master}$ clang++ main.cpp
main.cpp:71:18: warning: rvalue references are a C++11 extension [-Wc++11-
extensions]
int function(int i)
^
1 warning generated.
stephen@hal:~/dev/src/playground/cpp{master}$ clang++ -std=c++98 main.cpp
main.cpp:71:18: warning: rvalue references are a C++11 extension [-Wc++11-
extensions]
int function(int i)
^
1 warning generated.
stephen@hal:~/dev/src/playground/cpp{master}$ clang++ -std=gnu++98 main.cpp
main.cpp:71:18: warning: rvalue references are a C++11 extension [-Wc++11-
extensions]
int function(int i)
^
1 warning generated.
stephen@hal:~/dev/src/playground/cpp{master}$ g++ -std=gnu++98 main.cpp
main.cpp:71:18: error: expected ‘,’ or ‘...’ before ‘’ token
main.cpp: In function ‘int function(int)’:
main.cpp:73:10: error: ‘i’ was not declared in this scope
This means that if(CLANG), we could list rvalue references as a c++98
feature, and specify -Wno-c++11-extensions as the flag. However, I don't
think that's a good idea. I just mention it for completeness. Similarly,
both clang and GCC accept variadic templates by default, also with a
warning. For anything that warns, I suggest we consider it not-available.
So, I think this is a two dimensional calculation. There is a standard axis
and a extension axis for the compiler flag, for GCC and clang at least. That
means that we could do something like this:
if(NOT CMAKE_CXX_COMPILER_VERSION VERSION_LESS 4.7)
list(APPEND CMAKE_CXX11_COMPILER_FEATURES
final
override
)
endif()
if(NOT CMAKE_CXX_COMPILER_VERSION VERSION_LESS 4.9)
list(APPEND CMAKE_CXX14_COMPILER_FEATURES
generalized_lambda_capture
return_type_deduction
)
endif()
# TODO: Add an appropriate GCC version check
list(APPEND CMAKE_CXX98_COMPILER_EXTENSIONS
gnu_template_instantiation
)
# TODO: Add an appropriate GCC version check
list(APPEND CMAKE_CXX14_COMPILER_EXTENSIONS
gnu_generalized_lambda_capture_no_auto
)
Assuming a c++14 only gnu_generalized_lambda_capture_no_auto extension to
allow non-use of auto, as described in section 5.1 here
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3418.pdf
but not part of the draft standard.
Then, in the implementation of target_compiler_feature,
list(FIND CMAKE_CXX11_COMPILER_FEATURES ${FEATURE_NAME} needs11)
list(FIND CMAKE_CXX11_COMPILER_EXTENSIONS ${FEATURE_NAME} needs11ext)
list(FIND CMAKE_CXX14_COMPILER_FEATURES ${FEATURE_NAME} needs14)
list(FIND CMAKE_CXX14_COMPILER_EXTENSIONS ${FEATURE_NAME} needs14ext)
if(NOT needs14 EQUAL -1)
set(standard 14)
elif(NOT needs14ext EQUAL -1)
set(standard 14)
set(extension TRUE)
elseif(NOT needs11 EQUAL -1)
set(standard 11)
elseif(NOT needs11ext EQUAL -1)
set(standard 11)
set(extension TRUE)
endif()
# ...
set_property(TARGET ${TARGET_NAME} PROPERTY CXX_STANDARD ${standard})
set_property(TARGET ${TARGET_NAME} PROPERTY CXX_EXTENSION ${extension})
Then, in cmLocalGenerator:
const char *standard = target-GetProperty(CXX_STANDARD);
bool ext = target-GetPropertyAsBool(CXX_EXTENSION);
const char *type = ext ? EXTENSION : STANDARD;
std::string compile_option =
CMAKE_CXX + std::string(standard)
+ _ + std::string(type) + _COMPILE_OPTION;
if (const char *opt =
target-GetMakefile()-GetDefinition(compile_option.c_str()))
{
this-AppendFlags(flags, opt);
}
And:
if (NOT CMAKE_CXX_COMPILER_VERSION VERSION_LESS 4.7)
set(CMAKE_CXX11_STANDARD_COMPILE_OPTION -std=c++11)
set(CMAKE_CXX11_EXTENSION_COMPILE_OPTION -std=gnu++11)
endif()
if(NOT
Re: [cmake-developers] C++11 and target_compiler_feature proposal
Brad King wrote: On 10/09/2013 12:21 PM, Rolf Eike Beer wrote: One thing that is currently unclear if the simulated compiler id stuff from Brad solves the problem of the Clang plugin running with gcc where one would get the gcc version as compiler version but the features are actually depending on the version of the Clang plugin. After the Clang platform files load the GNU files to get the flags they will have to do their own logic to populate the feature lists. They can pass some indicator variable into the GNU files to block the GNU feature lists. The mode of operation of clang under discussion is not a 'normal' mode, but a mode in which clang and gcc aare both used, if I understood what Eike told me. I what is being discussed is either this: http://dragonegg.llvm.org/ or this: http://llvm.org/releases/2.9/docs/CommandGuide/html/llvmgcc.html which I think is deprecated. Eike, can you provide (a link to) more information on the problem you described to me before? Thanks, Steve. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] C++11 and target_compiler_feature proposal
Brad King wrote:
Steve, please explain your proposal in more detail. How does the list of
requested features get mapped to the proper -std=cxx11 or equivalent flag?
In my branch that is determined by which list the feature appears in. Eg,
from GNU-CXX.cmake:
if(NOT CMAKE_CXX_COMPILER_VERSION VERSION_LESS 4.7)
list(APPEND CMAKE_CXX11_COMPILER_FEATURES
final
override
)
endif()
if(NOT CMAKE_CXX_COMPILER_VERSION VERSION_LESS 4.9)
list(APPEND CMAKE_CXX14_COMPILER_FEATURES
generalized_lambda_capture
return_type_deduction
)
endif()
Then, in the implementation of target_compiler_feature,
list(FIND CMAKE_CXX11_COMPILER_FEATURES ${FEATURE_NAME} needs11)
list(FIND CMAKE_CXX14_COMPILER_FEATURES ${FEATURE_NAME} needs14)
list(FIND CMAKE_CXX17_COMPILER_FEATURES ${FEATURE_NAME} needs17)
if(NOT needs17 EQUAL -1)
set(standard 17)
elseif(NOT needs14 EQUAL -1)
set(standard 14)
elseif(NOT needs11 EQUAL -1)
set(standard 11)
endif()
# ...
set_property(TARGET ${TARGET_NAME} PROPERTY CXX_STANDARD ${standard})
Then, in cmLocalGenerator:
const char *standard = target-GetProperty(CXX_STANDARD);
std::string compile_option =
CMAKE_CXX + std::string(standard) + _STANDARD_COMPILE_OPTION;
if (const char *opt =
target-GetMakefile()-GetDefinition(compile_option.c_str()))
{
this-AppendFlags(flags, opt);
}
This is where I have an open question in the branch:
# TODO: Gnu extensions supported by -std=gnu++98 ?
# And others.
http://gcc.gnu.org/onlinedocs/gcc-4.8.0/gcc/C-Dialect-Options.html#C-Dialect-Options
# TODO: Maybe instead we should define like this:
#
# set(CMAKE_C_COMPILE_OPTIONS_STD -std=)
# set(CMAKE_CXX_COMPILE_OPTIONS_STD -std=)
#
# so that the CXX_STANDARD target property can contain the argument string
# (including possibly extensions).
# That might call for some kind of mapping though because XL uses different
# values (eg extended0x)
if (NOT CMAKE_CXX_COMPILER_VERSION VERSION_LESS 4.7)
set(CMAKE_CXX11_STANDARD_COMPILE_OPTION -std=c++11)
endif()
if(NOT CMAKE_CXX_COMPILER_VERSION VERSION_LESS 4.9
# AND VERSION_LESS 4.11 # Speculative
)
set(CMAKE_CXX14_STANDARD_COMPILE_OPTION -std=c++1y)
endif()
# if (NOT CMAKE_CXX_COMPILER_VERSION VERSION_LESS 4.11) # Speculative
# set(CMAKE_CXX14_STANDARD_COMPILE_OPTION -std=c++14)
# endif()
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] C++11 and target_compiler_feature proposal
Brad King wrote: Steve, Eike, Now that 2.8.12 is tagged I'd like to revive the work to support C++11 features. I met Eike in person today at Qt DevDays and talked about this topic a bit. The way forward is for me to get the infrastructure in place by cleaning up my branch. I'll aim for handling a single feature. Then Eike will help with encoding the information in the Modules files and the fallback compile tests. We'll initially defer the concept of generating a header file with defines/MyStaticAssert etc. I'll try to get a reviewable and first-feature-complete infrastructure branch together soon. Thanks, Steve. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] C++11 and target_compiler_feature proposal
On 10/09/2013 10:51 AM, Stephen Kelly wrote: I met Eike in person today at Qt DevDays and talked about this topic a bit. The way forward is for me to get the infrastructure in place by cleaning up my branch. I'll aim for handling a single feature. Then Eike will help with encoding the information in the Modules files and the fallback compile tests. We'll initially defer the concept of generating a header file with defines/MyStaticAssert etc. I'll try to get a reviewable and first-feature-complete infrastructure branch together soon. Fantastic, thanks! -Brad -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] C++11 and target_compiler_feature proposal
On 10/09/2013 10:44 AM, Stephen Kelly wrote:
if(NOT needs17 EQUAL -1)
set(standard 17)
elseif(NOT needs14 EQUAL -1)
set(standard 14)
elseif(NOT needs11 EQUAL -1)
set(standard 11)
endif()
# ...
set_property(TARGET ${TARGET_NAME} PROPERTY CXX_STANDARD ${standard})
This assumes a linear ordering among standards, which is true for the
actual standards, but may not be true for the compiler feature levels.
For example, the GNU compiler has a gnu variant branching off from
each standard level.
This is where I have an open question in the branch:
# TODO: Gnu extensions supported by -std=gnu++98 ?
# And others.
http://gcc.gnu.org/onlinedocs/gcc-4.8.0/gcc/C-Dialect-Options.html#C-Dialect-Options
Perhaps each feature can map to the minimum standard spec flag
it needs:
if(NOT CMAKE_CXX_COMPILER_VERSION VERSION_LESS 4.7)
set(CMAKE_CXX_FEATURE_FLAG_final -std=c++11)
set(CMAKE_CXX_FEATURE_FLAG_override -std=c++11)
endif()
if(NOT CMAKE_CXX_COMPILER_VERSION VERSION_LESS 4.9)
set(CMAKE_CXX_FEATURE_FLAG_generalized_lambda_capture -std=c++1y)
set(CMAKE_CXX_FEATURE_FLAG_return_type_deduction -std=c++1y)
endif()
Then have a graph of flags subsuming others:
set(CMAKE_CXX_STANDARD_SUBSUMES_-std=c++1y -std=c++11)
Then from the needed features, their corresponding flags,
and the subsume graph, compute the possible flags.
Then provide a way for the project and/or user to specify
their preferred flag and use it or error if it is not one
of those possible. If no preference is given, choose the
oldest flag.
-Brad
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] C++11 and target_compiler_feature proposal
Am Mittwoch, 9. Oktober 2013, 16:51:42 schrieb Stephen Kelly: Brad King wrote: Steve, Eike, Now that 2.8.12 is tagged I'd like to revive the work to support C++11 features. I met Eike in person today at Qt DevDays and talked about this topic a bit. The way forward is for me to get the infrastructure in place by cleaning up my branch. I'll aim for handling a single feature. Then Eike will help with encoding the information in the Modules files and the fallback compile tests. We'll initially defer the concept of generating a header file with defines/MyStaticAssert etc. I'll try to get a reviewable and first-feature-complete infrastructure branch together soon. The idea that we agreed upon (or basically: that Steve proposed and which I didn't fully understand until today) is that there will be a list of supported features for every compiler and version. Usually CMake will just use that list when it goes to determine if it could satisfy the requested features from the user. If the user believes the list is wrong or simply has a compiler currently not in the list he can request to do test-compiles for everything requested and use that results. In fact the testcase on all platforms will just do exactly that: request all features and compare it with the static list. So basically this is just a pre-populated cache. Afterwards CMake will go through several lists to find out if a compiler flag is needed to get that feature enabled. If those features are in the public interface of a library target they will be populated upwards. One thing that is currently unclear if the simulated compiler id stuff from Brad solves the problem of the Clang plugin running with gcc where one would get the gcc version as compiler version but the features are actually depending on the version of the Clang plugin. Steve, anything important I missed? Eike signature.asc Description: This is a digitally signed message part. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] C++11 and target_compiler_feature proposal
Am Mittwoch, 9. Oktober 2013, 15:54:18 schrieb Brad King: On 10/09/2013 12:21 PM, Rolf Eike Beer wrote: One thing that is currently unclear if the simulated compiler id stuff from Brad solves the problem of the Clang plugin running with gcc where one would get the gcc version as compiler version but the features are actually depending on the version of the Clang plugin. After the Clang platform files load the GNU files to get the flags they will have to do their own logic to populate the feature lists. They can pass some indicator variable into the GNU files to block the GNU feature lists. The question is if that plugin situation is actually detectable. I understood the situation that you fixed to be a clang binary that just understands the other compilers arguments. In the situation I mean you have actually 2 compilers involved. Eike signature.asc Description: This is a digitally signed message part. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
