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
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
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
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
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
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
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
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
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
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
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
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
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.
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
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)
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
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)
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.
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
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
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
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
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
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
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
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
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
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
28 matches
Mail list logo
