Re: [cmake-developers] Please review CXXFeatures.cmake
On 09/20/2013 03:42 PM, Rolf Eike Beer wrote: Having the interface in a full-featured C++11 way is step 2 or 3 on the way. I would like to solve the first step first. The problem is that the solution to the later steps cannot be built directly on top of your proposal for the first step. Steve's proposal elsewhere in this thread will cover everything needed. I don't think it is actually very complicated either. You two just need to shuffle the logic you (Eike) have already constructed to compute available features into the right places. -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] Please review CXXFeatures.cmake
Am Donnerstag, 15. August 2013, 14:37:42 schrieb Stephen Kelly: Stephen Kelly wrote: Stephen Kelly wrote: I still think you should revisit my review mail on point 2 too. Something that becomes possible when thinking about the above and target properties is interface requirements. I've implemented a prototype which has better API than your module. In my concept: * Applying the -std=c++11 flag is the responsibility of CMake, not the user. * CMake determines the -std= flag to use (GCC 4.9 has -std=c++1y by now). It won't add '-std=c++11 -std=c++14', but just '-std=c++14' * Required compiler features are scoped to targets. Can I get this globally? So I define once that all targets in my project get this? [Reading further] I assume I can set a global or directory property that will then propagate to all targets below. * Target properties are set, exported and transitively evaluated track the compiler features required. * Compiler requirements can be optional, in which case -D defines are generated in the (PUBLIC) COMPILE_DEFINITIONS * The -D defines are for scoping or replacement, depending on what the feature calls for. * Required compiler features are listed in the INTERFACE of exported targets. CMake evaluates whether the compiler is capable of using the IMPORTED targets it is supposed to use transitively, in a similar way to the POSITION_INDEPENDENT_CODE feature. * A new command target_compiler_feature is introduced with two signatures: target_compiler_feature(target PUBLIC|PRIVATE REQUIRED feature1 [feature2 ...]) target_compiler_feature(target PUBLIC|PRIVATE OPTIONAL feature DEFINE define_name) * Another non-target-scoped command could be introduced, similar to target_compile_options - add_compile_options. This is better in many noteworthy ways to the cxx11 topic in the stage. It solves an entirely different problem. My topic makes CMake detect which C++ features the compiler supports. Your topic is about how to get this to the targets and propagate it to the targets that use them. 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] Please review CXXFeatures.cmake
On 09/20/2013 04:32 PM, Rolf Eike Beer wrote: It solves an entirely different problem. My topic makes CMake detect which C++ features the compiler supports. Your topic is about how to get this to the targets and propagate it to the targets that use them. See the thread that split off from this one here: http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/7795 titled c++ feature detection and usage requirements. The proposal covers both report of available features and propagation of requirements. -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] Please review CXXFeatures.cmake
On 08/14/2013 02:19 PM, Rolf Eike Beer wrote: Perhaps you can also teach the test to print out the CMakeFiles/CMakeOutput.log and CMakeFiles/CMakeError.log content at the end when it got unexpected results. Will look into it. Thanks for working on this topic and getting the dashboard cleaned up! Now that it has stabilized please rebase -i the topic to squash in the fixup commits to the right places. Please rewrite the entire topic back through 8ea3dcd2 so that the revised version is clearly separated from the original. If the head of the revised topic is identical to the original then it will merge to next again cleanly. 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] Please review CXXFeatures.cmake
Stephen Kelly wrote:
Stephen Kelly wrote:
I still think you should revisit my review mail on point 2 too.
Something that becomes possible when thinking about the above and target
properties is interface requirements.
I've implemented a prototype which has better API than your module.
In my concept:
* Applying the -std=c++11 flag is the responsibility of CMake, not the user.
* CMake determines the -std= flag to use (GCC 4.9 has -std=c++1y by now). It
won't add '-std=c++11 -std=c++14', but just '-std=c++14'
* Required compiler features are scoped to targets.
* Target properties are set, exported and transitively evaluated track the
compiler features required.
* Compiler requirements can be optional, in which case -D defines are
generated in the (PUBLIC) COMPILE_DEFINITIONS
* The -D defines are for scoping or replacement, depending on what the
feature calls for.
* Required compiler features are listed in the INTERFACE of exported
targets. CMake evaluates whether the compiler is capable of using the
IMPORTED targets it is supposed to use transitively, in a similar way to the
POSITION_INDEPENDENT_CODE feature.
* A new command target_compiler_feature is introduced with two signatures:
target_compiler_feature(target PUBLIC|PRIVATE
REQUIRED feature1 [feature2 ...])
target_compiler_feature(target PUBLIC|PRIVATE
OPTIONAL feature DEFINE define_name)
* Another non-target-scoped command could be introduced, similar to
target_compile_options - add_compile_options.
This is better in many noteworthy ways to the cxx11 topic in the stage.
Brad, do you have any response to any part of anything I wrote about that
topic?
Thanks,
Steve.
#include foo.h
A::A(int i, void *p)
: num(i), ptr(p)
{
}
A::A(const A other)
: num(other.num), ptr(other.ptr)
{
}
A::~A()
{
}
A A::operator=(const A other)
{
num = other.num;
ptr = other.ptr;
return *this;
}
B::B(int i, void *p)
: A(i, ptr)
{
}
#include utility
templatetypename T
struct Factory
{
// Variadic templates and macros required to use this library by design. Not guarded by any macro.
templatetypename... Args
static T Create(Args... args) { return T(std::forwardArgs(args)...); }
};
#define CREATE(TYPE, ...) Factory TYPE ::Create(__VA_ARGS__)
class A
{
templatetypename friend class Factory;
friend class B;
int num;
void *ptr;
A(int i, void *p = Foo_NULLPTR);
public:
#if Foo_RVALUE_REFS
inline A(A other) : num(other.num), ptr(other.ptr)
{
other.num = 0;
other.ptr = 0;
}
inline A operator=(A other)
{
std::swap(num, other.num);
std::swap(ptr, other.ptr);
return *this;
}
#endif
inline A(const A other);
inline A operator=(const A other);
virtual ~A();
virtual void doSomething() {}
virtual void doSomethingElse() {}
};
class B : public A
{
templatetypename friend class Factory;
B(int i, void *ptr = Foo_NULLPTR);
public:
void doSomething() Foo_OVERRIDE {}
void doSomethingElse() Foo_FINAL {}
};
#include foo.h
int main(int argc, char **argv)
{
auto a = CREATE(A, 47, new long);
auto b = CREATE(B, 42);
}
# FIXME: Encode this stuff into Modules/Compiler/*.cmake
if(CMAKE_CXX_COMPILER_ID STREQUAL GNU)
set(CMAKE_C_COMPILER_FEATURES)
if(NOT CMAKE_C_COMPILER_VERSION VERSION_LESS 4.3)
list(APPEND CMAKE_C_COMPILER_FEATURES
variadic_macros
)
endif()
set(CMAKE_C99_STANDARD_COMPILE_OPTION -std=c99)
# FIXME: This feature listing is not complete.
set(CMAKE_CXX98_COMPILER_FEATURES)
if(NOT CMAKE_CXX_COMPILER_VERSION VERSION_LESS 4.3)
list(APPEND CMAKE_CXX98_COMPILER_FEATURES
member_templates
template_template_parameters
template_friends
)
endif()
set(CMAKE_CXX11_COMPILER_FEATURES)
if(NOT CMAKE_CXX_COMPILER_VERSION VERSION_LESS 4.3)
list(APPEND CMAKE_CXX11_COMPILER_FEATURES
decltype
rvalue_refs
static_assert
variadic_macros
)
endif()
if(NOT CMAKE_CXX_COMPILER_VERSION VERSION_LESS 4.4)
list(APPEND CMAKE_CXX11_COMPILER_FEATURES
auto_type
default_members
deleted_members
variadic_templates
)
endif()
if(NOT CMAKE_CXX_COMPILER_VERSION VERSION_LESS 4.6)
list(APPEND CMAKE_CXX11_COMPILER_FEATURES
nullptr
)
endif()
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
# binary_literals
generalized_lambda_capture
return_type_deduction
)
endif()
set(CMAKE_CXX_COMPILER_FEATURES
binary_literals
${CMAKE_CXX98_COMPILER_FEATURES}
${CMAKE_CXX11_COMPILER_FEATURES}
${CMAKE_CXX14_COMPILER_FEATURES}
)
if (NOT CMAKE_CXX_COMPILER_VERSION VERSION_LESS 4.7)
set(CMAKE_CXX11_STANDARD_COMPILE_OPTION -std=c++11)
elseif(NOT CMAKE_CXX_COMPILER_VERSION
Re: [cmake-developers] Please review CXXFeatures.cmake
On 08/13/2013 01:54 PM, Rolf Eike Beer wrote: Brad King wrote: On Win64-vs10-Tv90 it is building with VS 10 but the compiler is VS 9. I'll switch that over to use CMAKE_CXX_COMPILER_VERSION as suggested below, the error will probably go away then. That worked. For Win32-mingw-gcc-4.5 and Win32-msys-gcc-4.5, does the MinGW port of the compiler support all the same features? It is GNU 4.5.0. I would have expected it so. The problem was the if(WIN32) condition for testing /Qstd=c++11 for the Intel compiler. It triggered on MinGW and of course that GNU compiler doesn't have the flag. Fixed: http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=51ce1aeb While at it I added logging of the try_compile output: http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=cabd6f87 This should help local investigations of the remaining failures. Perhaps you can also teach the test to print out the CMakeFiles/CMakeOutput.log and CMakeFiles/CMakeError.log content at the end when it got unexpected results. For Windows-icl-11.1-*, why do the expected results not just match for this version? That is a question I wanted to bring up, too. Can you log into that machine and get me the intermediate results of the try_compile calls? It seems to have worked last night anyway. It also worked for me with local testing of the above-linked changes. -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] Please review CXXFeatures.cmake
Am Mittwoch, 14. August 2013, 14:02:35 schrieb Brad King: On 08/13/2013 01:54 PM, Rolf Eike Beer wrote: Brad King wrote: On Win64-vs10-Tv90 it is building with VS 10 but the compiler is VS 9. I'll switch that over to use CMAKE_CXX_COMPILER_VERSION as suggested below, the error will probably go away then. That worked. For Win32-mingw-gcc-4.5and Win32-msys-gcc-4.5, does the MinGW port of the compiler support all the same features? It is GNU 4.5.0. I would have expected it so. The problem was the if(WIN32) condition for testing /Qstd=c++11 for the Intel compiler. It triggered on MinGW and of course that GNU compiler doesn't have the flag. Fixed: http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=51ce1aeb Ah, stupid mistake. While at it I added logging of the try_compile output: http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=cabd6f87 This should help local investigations of the remaining failures. Perhaps you can also teach the test to print out the CMakeFiles/CMakeOutput.log and CMakeFiles/CMakeError.log content at the end when it got unexpected results. Will look into it. For Windows-icl-11.1-*, why do the expected results not just match for this version? That is a question I wanted to bring up, too. Can you log into that machine and get me the intermediate results of the try_compile calls? It seems to have worked last night anyway. It also worked for me with local testing of the above-linked changes. Freaky. 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] Please review CXXFeatures.cmake
Stephen Kelly wrote: I still think you should revisit my review mail on point 2 too. Something that becomes possible when thinking about the above and target properties is interface requirements. If my library uses 'final' unguarded by macros in my headers, then I want to communicate through the target that a compiler supporting that feature is required. set_property(TARGET foo PROPERTY INTERFACE_CXX_COMPILER_FEATURE_final 1) which would work similiarly to (and using the same infrastructure as) INTERFACE_POSITION_INDEPENDENT_CODE. 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] Please review CXXFeatures.cmake
On 08/02/2013 05:20 PM, Rolf Eike Beer wrote: Brad, please don't merge that Do all of the remaining test failures need the cxx-flags topic to fix? http://open.cdash.org/testSummary.php?project=1name=Module.FindCXXFeaturesdate=2013-08-13 I'd like to get these resolved or revert the topic because the noise on the dashboard is very distracting while trying to get 2.8.12-rc1 out. On Win64-vs10-Tv90 it is building with VS 10 but the compiler is VS 9. The logic that sets MSVC_VERSION should be correct in this case so I'm not sure what is causing the expected results to mismatch. For Win32-mingw-gcc-4.5 and Win32-msys-gcc-4.5, does the MinGW port of the compiler support all the same features? It is GNU 4.5.0. For the Linux*-LSB4.0 builds with GNU 4.3.2: CMake Error at CMakeLists.txt:203 (message): C++ feature 'CXXFeatures_cstdint_header_FOUND' was detected, but not expected the LSB-enforcing compilers may provide that header. For MacOSX10.7-Xcode43-ub, it is the Apple port of the GNU 4.2.1 so there are more features than expected. For Windows-icl-11.1-*, why do the expected results not just match for this version? Also, IMO if (CMAKE_COMPILER_IS_GNUCXX) and elseif (MSVC) should use CMAKE_CXX_COMPILER_ID instead just like the rest of the cases. 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] Please review CXXFeatures.cmake
Brad King wrote: On 08/02/2013 05:20 PM, Rolf Eike Beer wrote: Brad, please don't merge that Do all of the remaining test failures need the cxx-flags topic to fix? No, since both are in next already everything that still shows up as a bug is a bug. http://open.cdash.org/testSummary.php?project=1name=Module.FindCXXFeatures date=2013-08-13 I'd like to get these resolved or revert the topic because the noise on the dashboard is very distracting while trying to get 2.8.12-rc1 out. I'm working on it. On Win64-vs10-Tv90 it is building with VS 10 but the compiler is VS 9. The logic that sets MSVC_VERSION should be correct in this case so I'm not sure what is causing the expected results to mismatch. The expected features seen here indicate that MSVC_VERSION is 1600 (i.e. VC10). Which is correct IMHO, as it gives the version of the suite, not the compiler. I'll switch that over to use CMAKE_CXX_COMPILER_VERSION as suggested below, the error will probably go away then. For Win32-mingw-gcc-4.5 and Win32-msys-gcc-4.5, does the MinGW port of the compiler support all the same features? It is GNU 4.5.0. I would have expected it so. For the Linux*-LSB4.0 builds with GNU 4.3.2: CMake Error at CMakeLists.txt:203 (message): C++ feature 'CXXFeatures_cstdint_header_FOUND' was detected, but not expected the LSB-enforcing compilers may provide that header. For MacOSX10.7-Xcode43-ub, it is the Apple port of the GNU 4.2.1 so there are more features than expected. Because of the Clang version mixup already discussed I plan to make the more features found than expected message a WARNING instead of an error. I can do this now and sort the other expected features out next week or so when you have the RC ready. This is only part of how we verify that the module works, not the module itself. For Windows-icl-11.1-*, why do the expected results not just match for this version? That is a question I wanted to bring up, too. Can you log into that machine and get me the intermediate results of the try_compile calls? Also, IMO if (CMAKE_COMPILER_IS_GNUCXX) and elseif (MSVC) should use CMAKE_CXX_COMPILER_ID instead just like the rest of the cases. Agreed, as above. 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] Please review CXXFeatures.cmake
Rolf Eike Beer wrote:
5)
This is not nice API:
#if defined (CXXFEATURES_NULLPTR_FOUND)
void *nix = nullptr;
#else /* CXXFEATURES_NULLPTR_FOUND */
void *nix = 0;
#endif /* CXXFEATURES_NULLPTR_FOUND */
Much better would be:
void *nix = CXXFEATURES_NULLPTR;
where -DCXXFEATURES_NULLPTR=0 or -DCXXFEATURES_NULLPTR=nullptr.
See what Qt does for other similar API decisions on what should be
defined to something (like nullptr, constexpr, final etc), and what
should be a 'guard' define like above (eg lambdas, variadic templates
etc).
Note also that by defining the CXXFEATURES_FINAL to something, you get to
use the 'sealed' extension, which does the same thing, and works with
VC2005. See qcompilerdetection.h.
The module returns just a list of CMake flags. How this is passed to the
user (header, defines, whatever) is currently something the user must
decide. I will not do anything fancy in the testcase for now.
Imagine I wanted to set Grantlee_FINAL to empty or final based on whether
c++11 was active or not. How would I do that?
I might do this:
# This seems like an API smell. With g++ I want to wrap the add_definitions
# in a condition for enabling c++11 at all. Does this mean that c++11
# features are not made available when using MSVC?
if(CXX11_COMPILER_FLAGS)
# Can't use add_compile_options as CXX11_COMPILER_FLAGS is a string, not
# a list.
# This means that -std=c++11 is also passed when linking.
set(CMAKE_CXX_FLAGS ${CMAKE_CXX_FLAGS} ${CXX11_COMPILER_FLAGS})
if (CXXFeatures_class_override_final_FOUND)
add_definitions(-DGrantlee_FINAL=final)
set(_final_defined 1)
endif()
endif()
if (NOT _final_defined)
add_definitions(-DGrantlee_FINAL=)
endif()
Do you have any more-real-world examples of what code using your module
would look like?
My c++ code would then look like:
struct A Grantlee_FINAL
{
int data;
};
However, now downstreams need to define Grantlee_FINAL to something in order
to compile. We can help of course by putting Grantlee_FINAL in the
INTERFACE_COMPILE_DEFINITIONS of Grantlee.
However, what do we define it to? We need to define it based on the
capabilities of the downstream. Ok, the way to do things like that in CMake
is generator expressions.
target_compile_definitions(Grantlee
INTERFACE Grantlee_FINAL=$$TARGET_PROPERTY:CXX11:final
)
So, if the consumer has the CXX11 property ON, then it will be defined to
'final'.
However, the problem is that there is no standard CXX11 target property. At
best, I'd choose a property name which is a de-facto standard. See point 3:
http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/6726/focus=7671
To repeat my point 5, the target_compile_definitions code might look more
like this:
set(msvc_genex $STREQUAL:$COMPILER_ID,MSVC)
set(msvc_sealed_min $NOT:$VERSION_LESS:$CXX_COMPILER_VERSION,1400)
set(msvc_sealed_max $VERSION_LESS:$CXX_COMPILER_VERSION,1700)
set(msvc_sealed $AND:${msvc_genex},${msvc_sealed_min},${msvc_sealed_max})
set(_use_sealed $AND:$TARGET_PROPERTY:CXX11,${msvc_sealed})
set(_use_final $AND:$TARGET_PROPERTY:CXX11,$NOT:${msvc_sealed})
set(cxx11_final $${_use_final}:final$${_use_sealed}:sealed)
target_compile_definitions(Grantlee
INTERFACE Grantlee_FINAL=${cxx11_final}
)
See https://qt.gitorious.org/qt/qtbase/commit/37a660c594a
I really think that's something that should be solved by your module. I
still think you should revisit my review mail on point 2 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] Please review CXXFeatures.cmake
On 08/01/2013 04:47 PM, Rolf Eike Beer wrote: Alexander Neundorf wrote: I'm not sure I would have made this a find-module, instead of a simple module which can be included and then provides a function, but I think this doesn't matter much. Because I get things like components for free then ;) Since it looks like a find module it is running as part of the all-find-modules tests: Tests/FindModulesExecuteAll/CMakeLists.txt Tests/CMakeOnly/AllFindModules/CMakeLists.txt Since this module is not really a find module and already has its own dedicated Module.CXXFeatures test, please teach the above two tests to skip it. - All three above tests are timing out on the Watcom build: http://open.cdash.org/viewTest.php?onlyfailedbuildid=2992340 Watcom interactively prompts in some error cases so it times out the automated tests. I've finally just taken the time to figure out how to suppress the prompt which I'll add in another topic. Anyway, the error occurs in one of the try_compile checks: [100%] Building CXX object CMakeFiles/cmTryCompileExec1059188181.dir/src.cxx.obj Error! E059: unable to open 'd=c++11' The corresponding flags.make has: CXX_FLAGS = -w=3 -xs -D_HAS_CXX11_FLAG -br -bm -d2 -std=c++11 The wcl386 compiler help shows -st touch stack through SS first You may need to hard-code answers for some compilers. - What is the expected behavior if one writes find_package(CXXFeatures QUIET) ? If this is supposed to be a find module then it should not have guaranteed failure cases like this: if (NOT CMAKE_CXX_COMPILER_LOADED) message(FATAL_ERROR CXXFeatures modules only works if language CXX is enabled) endif () It should respond with NOTFOUND for everything if CXX is not enabled IMO. 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] Please review CXXFeatures.cmake
Brad King wrote: On 08/01/2013 04:47 PM, Rolf Eike Beer wrote: Alexander Neundorf wrote: I'm not sure I would have made this a find-module, instead of a simple module which can be included and then provides a function, but I think this doesn't matter much. Because I get things like components for free then ;) Since it looks like a find module it is running as part of the all-find-modules tests: Tests/FindModulesExecuteAll/CMakeLists.txt Tests/CMakeOnly/AllFindModules/CMakeLists.txt Since this module is not really a find module and already has its own dedicated Module.CXXFeatures test, please teach the above two tests to skip it. Ok, I'll move the test from Tests/Module/CXXFeatures to Tests/Module/FindCXXFeatures and then tell those tests to ignore any Find* in that directory. - All three above tests are timing out on the Watcom build: http://open.cdash.org/viewTest.php?onlyfailedbuildid=2992340 Watcom interactively prompts in some error cases so it times out the automated tests. I've finally just taken the time to figure out how to suppress the prompt which I'll add in another topic. Anyway, the error occurs in one of the try_compile checks: [100%] Building CXX object CMakeFiles/cmTryCompileExec1059188181.dir/src.cxx.obj Error! E059: unable to open 'd=c++11' The corresponding flags.make has: CXX_FLAGS = -w=3 -xs -D_HAS_CXX11_FLAG -br -bm -d2 -std=c++11 The wcl386 compiler help shows -st touch stack through SS first You may need to hard-code answers for some compilers. - Bug 14339, add Watcom I think. What is the expected behavior if one writes find_package(CXXFeatures QUIET) ? If this is supposed to be a find module then it should not have guaranteed failure cases like this: if (NOT CMAKE_CXX_COMPILER_LOADED) message(FATAL_ERROR CXXFeatures modules only works if language CXX is enabled) endif () It should respond with NOTFOUND for everything if CXX is not enabled IMO. Well, including this module without a C++ compiler just can't work. Adding such a QUIET-bypass is possible, but I don't see a value in it. This case an only happen if one explicitely disables C++ and later conditionally enables it. But this conditionally (i.e. if(...)) could also cover the call to this module. This also breaks if you do find_package(Qt4 QUIET) without C++ enabled, and probably others (Boost?). Eike -- 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] Please review CXXFeatures.cmake
Brad King wrote: On 08/02/2013 05:20 PM, Rolf Eike Beer wrote: Brad, please don't merge that next week Okay. We're preparing 2.8.12 rc1 this week so I think we'll hold off CXXFeatures until after 2.8.12 anyway. I have pushed a fix for 14303 to next. Please have a look. Without this parallel memcheck is very broken (which would be a regression to 2.8.11). 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] Please review CXXFeatures.cmake
Rolf Eike Beer wrote: Am Sonntag, 28. April 2013, 13:57:26 schrieb Rolf Eike Beer: One question I see increasingly often is how do I test for C++11 support or for specific parts of that. For 2.8.12 I plan to include the check module I wrote for that a while back, and that I have reworked in the last weeks. You can find the current state in the rework branch of this repository: Ok, I finally put it into the CMake repository: I have some feedback: 1) A recent commit in the topic does this: -g++ seems to support constexpr since 4.5 even if their support page says 4.6 It has been common for compilers to implement support for features like this, but have some fundamental brokenness in earlier versions. Your test which enables the use of constexpr might not exercise the feature enough to hit the fundamental brokenness, but that doesn't mean it's an edge-case. It would be better not to second-guess the version gcc says it supports features in. 2) Given that you're gathering the versions of each feature availability anyway, and given that boost.config and qcompilerdetection.h have the same information, there is no need for all users of the module to run all these try_compiles for all projects. Think of the energy waste :)! I suggest you use CMAKE_CXX_COMPILER_ID and CMAKE_CXX_COMPILER_VERSION to hardcode the features. You could even do so for known compilers, and leave the try_compile stuff for not-known compilers if you really want to, but I don't think that's worthwhile maintenance. 3) CXX11_COMPILER_FLAGS is not really the 'modern' way to specify compiler flags, as of recent CMake versions. See for example the reasoning here: http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/6876/focus=6890 regarding *_FLAGS, which is a whitespace delimited string, and COMPILE_OPTIONS, which is a regular ';' delimited CMake list. The modern way to do something like that is a target property and a way to set the default. See for example commit bd3496300262bd26073ce03e020731c592249148 (Refactor generation of shared library flags, 2012-05-30). The set(CMAKE_POSITION_INDEPENDENT_CODE ON) feature is enabled by this-SetPropertyDefault(POSITION_INDEPENDENT_CODE, 0); in cmTarget. For more/similar, see commit cd1fa537a03377974a4d0a27e592785f931a41e5 (Add a COMPILE_OPTION for a VISIBILITY_INLINES_HIDDEN target property., 2013-05-23) and 0e9f4bc00c6b26f254e74063e4026ac33b786513 (Introduce target property LANG_VISIBILITY_PRESET, 2013-05-18). I added a patch to my clone with the start of CMAKE_CXX_COMPILE_OPTIONS_STD_CXX11 https://gitorious.org/~steveire/cmake/steveires-cmake/commits/std-cxx-target-property but it didn't get anywhere yet: http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/4106 4) The COMPILE_OPTIONS for clang+apple might have to include -stdlib=libc++ for binary compatibility reasons if any of the dependencies use c++11 std library API in their interface and use libc++. See what I wrote about that here: http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/5813 5) This is not nice API: #if defined (CXXFEATURES_NULLPTR_FOUND) void *nix = nullptr; #else /* CXXFEATURES_NULLPTR_FOUND */ void *nix = 0; #endif /* CXXFEATURES_NULLPTR_FOUND */ Much better would be: void *nix = CXXFEATURES_NULLPTR; where -DCXXFEATURES_NULLPTR=0 or -DCXXFEATURES_NULLPTR=nullptr. See what Qt does for other similar API decisions on what should be defined to something (like nullptr, constexpr, final etc), and what should be a 'guard' define like above (eg lambdas, variadic templates etc). Note also that by defining the CXXFEATURES_FINAL to something, you get to use the 'sealed' extension, which does the same thing, and works with VC2005. See qcompilerdetection.h. 6) It is also unfortunate that because your solution is to define things on the command line, you can't easily define something for static_assert. See CMakeStaticAssert for example, which works for all compilers on the dashboard. For that reason, I'll continue to recommend that anyone using Qt and CMake does not use your module, but instead uses the defines from Qt. Ditto for anyone using boost. A missing piece that your module provides is determining the features at CMake time. However, if Qt is found, that can be done with a single try_compile of qglobal.h to get that information into a form usable to CMake. That's a feature I can add to Qt 5 soon, and something similar can be done to process the information from boost.config. 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] Please review CXXFeatures.cmake
On 08/02/2013 05:20 PM, Rolf Eike Beer wrote: Brad, please don't merge that next week Okay. We're preparing 2.8.12 rc1 this week so I think we'll hold off CXXFeatures until after 2.8.12 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] Please review CXXFeatures.cmake
Brad King wrote: On 08/02/2013 05:20 PM, Rolf Eike Beer wrote: Brad, please don't merge that next week Okay. We're preparing 2.8.12 rc1 this week so I think we'll hold off CXXFeatures until after 2.8.12 anyway. I think 14303 should be resolved first as it would break parallel memtest for everyone using valgrind. And probably 14335 too, this shouldn't be too hard to fix, I just did not have time on the weekend to look into this. For the memtest one I'm open for all suggestions on how to get this fixed. 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] Please review CXXFeatures.cmake
Stephen Kelly wrote: Rolf Eike Beer wrote: Am Sonntag, 28. April 2013, 13:57:26 schrieb Rolf Eike Beer: One question I see increasingly often is how do I test for C++11 support or for specific parts of that. For 2.8.12 I plan to include the check module I wrote for that a while back, and that I have reworked in the last weeks. You can find the current state in the rework branch of this repository: Ok, I finally put it into the CMake repository: I have some feedback: 1) A recent commit in the topic does this: -g++ seems to support constexpr since 4.5 even if their support page says 4.6 It has been common for compilers to implement support for features like this, but have some fundamental brokenness in earlier versions. Your test which enables the use of constexpr might not exercise the feature enough to hit the fundamental brokenness, but that doesn't mean it's an edge-case. It would be better not to second-guess the version gcc says it supports features in. I'm happy for all updated checks, so push a patch on that branch ;) 2) Given that you're gathering the versions of each feature availability anyway, and given that boost.config and qcompilerdetection.h have the same information, there is no need for all users of the module to run all these try_compiles for all projects. Think of the energy waste :)! I suggest you use CMAKE_CXX_COMPILER_ID and CMAKE_CXX_COMPILER_VERSION to hardcode the features. You could even do so for known compilers, and leave the try_compile stuff for not-known compilers if you really want to, but I don't think that's worthwhile maintenance. We already found out that this is a bad idea for Apple, I still don't completely get it right for g++ and XL, and it isn't the way that CMake works for other things (I'm thinking of e.g. OpenMP). And qcompilerdetection.h is a good example of how I would not want it, last time I looked they just deactivated every feature on Clang. The idea I have about CMake is that it would check for stuff on any compiler I throw on it, so it would just report correct results for this that haven't been tested before (PGI? MipsPro? gcc 2?). 3) CXX11_COMPILER_FLAGS is not really the 'modern' way to specify compiler flags, as of recent CMake versions. See for example the reasoning here: http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/6876/focus =6890 regarding *_FLAGS, which is a whitespace delimited string, and COMPILE_OPTIONS, which is a regular ';' delimited CMake list. The modern way to do something like that is a target property and a way to set the default. See for example commit bd3496300262bd26073ce03e020731c592249148 (Refactor generation of shared library flags, 2012-05-30). The set(CMAKE_POSITION_INDEPENDENT_CODE ON) feature is enabled by this-SetPropertyDefault(POSITION_INDEPENDENT_CODE, 0); in cmTarget. For more/similar, see commit cd1fa537a03377974a4d0a27e592785f931a41e5 (Add a COMPILE_OPTION for a VISIBILITY_INLINES_HIDDEN target property., 2013-05-23) and 0e9f4bc00c6b26f254e74063e4026ac33b786513 (Introduce target property LANG_VISIBILITY_PRESET, 2013-05-18). I added a patch to my clone with the start of CMAKE_CXX_COMPILE_OPTIONS_STD_CXX11 https://gitorious.org/~steveire/cmake/steveires-cmake/commits/std-cxx-targe t-property but it didn't get anywhere yet: http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/4106 I'm not sure about this. I just return the flag that is needed. The user has to put this into the compiler flags on a global or per target base. I don't do anything with it. 4) The COMPILE_OPTIONS for clang+apple might have to include -stdlib=libc++ for binary compatibility reasons if any of the dependencies use c++11 std library API in their interface and use libc++. See what I wrote about that here: http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/5813 I don't see how this is different with and without C++11, so how does it affect this module in a way that would not affect the user anyway? 5) This is not nice API: #if defined (CXXFEATURES_NULLPTR_FOUND) void *nix = nullptr; #else /* CXXFEATURES_NULLPTR_FOUND */ void *nix = 0; #endif /* CXXFEATURES_NULLPTR_FOUND */ Much better would be: void *nix = CXXFEATURES_NULLPTR; where -DCXXFEATURES_NULLPTR=0 or -DCXXFEATURES_NULLPTR=nullptr. See what Qt does for other similar API decisions on what should be defined to something (like nullptr, constexpr, final etc), and what should be a 'guard' define like above (eg lambdas, variadic templates etc). Note also that by defining the CXXFEATURES_FINAL to something, you get to use the 'sealed' extension, which does the same thing, and works with VC2005. See qcompilerdetection.h. The module returns just a list of CMake flags. How this is passed to the user (header, defines, whatever) is currently something the user must decide. I
Re: [cmake-developers] Please review CXXFeatures.cmake
Rolf Eike Beer wrote: Given that you're gathering the versions of each feature availability anyway, and given that boost.config and qcompilerdetection.h have the same information, there is no need for all users of the module to run all these try_compiles for all projects. Think of the energy waste :)! I suggest you use CMAKE_CXX_COMPILER_ID and CMAKE_CXX_COMPILER_VERSION to hardcode the features. You could even do so for known compilers, and leave the try_compile stuff for not-known compilers if you really want to, but I don't think that's worthwhile maintenance. We already found out that this is a bad idea for Apple, No we didn't :). The AppleClang vs VanillaClang version issue is something that needs to be solved anyway. I still don't completely get it right for g++ and XL, and it isn't the way that CMake works for other things (I'm thinking of e.g. OpenMP). And qcompilerdetection.h is a good example of how I would not want it, last time I looked they just deactivated every feature on Clang. I don't know what you're talking about, but I am certain you're mistaken in a simple interpretation of what you wrote. The idea I have about CMake is that it would check for stuff on any compiler I throw on it, so it would just report correct results for this that haven't been tested before (PGI? MipsPro? gcc 2?). ... Stephen Kelly wrote: I suggest you use CMAKE_CXX_COMPILER_ID and CMAKE_CXX_COMPILER_VERSION to hardcode the features. You could even do so for known compilers, and leave the try_compile stuff for not-known compilers if you really want to, but I don't think that's worthwhile maintenance. ... 4) The COMPILE_OPTIONS for clang+apple might have to include -stdlib=libc++ for binary compatibility reasons if any of the dependencies use c++11 std library API in their interface and use libc++. See what I wrote about that here: http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/5813 I don't see how this is different with and without C++11, so how does it affect this module in a way that would not affect the user anyway? You might have to investigate, for example, how system c++ libraries are compiled. I'm not familiar enough with APPLE to know what kind of c++ libraries it comes with. 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] Please review CXXFeatures.cmake
Rolf Eike Beer wrote: Stephen Kelly wrote: Rolf Eike Beer wrote: Given that you're gathering the versions of each feature availability anyway, and given that boost.config and qcompilerdetection.h have the same information, there is no need for all users of the module to run all these try_compiles for all projects. Think of the energy waste :)! I suggest you use CMAKE_CXX_COMPILER_ID and CMAKE_CXX_COMPILER_VERSION to hardcode the features. You could even do so for known compilers, and leave the try_compile stuff for not-known compilers if you really want to, but I don't think that's worthwhile maintenance. We already found out that this is a bad idea for Apple, No we didn't :). The AppleClang vs VanillaClang version issue is something that needs to be solved anyway. The which c++ lib is used one, too. So you can only score one point, either this one or the one below ;) Not really. The set of language features implemented by the compiler is independent of the stdlib implementation and completeness. 4) The COMPILE_OPTIONS for clang+apple might have to include -stdlib=libc++ for binary compatibility reasons if any of the dependencies use c++11 std library API in their interface and use libc++. See what I wrote about that here: http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/5813 I don't see how this is different with and without C++11, so how does it affect this module in a way that would not affect the user anyway? You might have to investigate, for example, how system c++ libraries are compiled. I'm not familiar enough with APPLE to know what kind of c++ libraries it comes with. Again, how does that affect this module? Yes, I see what you mean. I suppose this issue of std library implementation is orthogonal to your module. However, I think a complete 'CMake support for c++11' concept would include diagnostic of transitively incompatible stdlib implementations (because it can be a common problem nowadays as both libstdcxx and libcxx are in the wild as c++11 library implementations), *and* compiler feature enabling. I guess you're only shooting for the latter, and not the 'complete package', but as I wrote before, I still think you should modernize regarding COMPILE_OPTIONS and target properties 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] Please review CXXFeatures.cmake
Stephen Kelly wrote: Rolf Eike Beer wrote: Given that you're gathering the versions of each feature availability anyway, and given that boost.config and qcompilerdetection.h have the same information, there is no need for all users of the module to run all these try_compiles for all projects. Think of the energy waste :)! I suggest you use CMAKE_CXX_COMPILER_ID and CMAKE_CXX_COMPILER_VERSION to hardcode the features. You could even do so for known compilers, and leave the try_compile stuff for not-known compilers if you really want to, but I don't think that's worthwhile maintenance. We already found out that this is a bad idea for Apple, No we didn't :). The AppleClang vs VanillaClang version issue is something that needs to be solved anyway. The which c++ lib is used one, too. So you can only score one point, either this one or the one below ;) I still don't completely get it right for g++ and XL, and it isn't the way that CMake works for other things (I'm thinking of e.g. OpenMP). And qcompilerdetection.h is a good example of how I would not want it, last time I looked they just deactivated every feature on Clang. I don't know what you're talking about, but I am certain you're mistaken in a simple interpretation of what you wrote. And I don't get what you write, but that is probably my fault. Anyway, I have looked into the header again, and the stuff seems to have been in there since it was split out of qglobal.h. So whatever I saw or think to have seen was probably wrong. But my point is still: if I have neither boost, nor Qt, nor Clang in the project I need a fallback solution anyway. So I could just always use this. 4) The COMPILE_OPTIONS for clang+apple might have to include -stdlib=libc++ for binary compatibility reasons if any of the dependencies use c++11 std library API in their interface and use libc++. See what I wrote about that here: http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/5813 I don't see how this is different with and without C++11, so how does it affect this module in a way that would not affect the user anyway? You might have to investigate, for example, how system c++ libraries are compiled. I'm not familiar enough with APPLE to know what kind of c++ libraries it comes with. Again, how does that affect this module? What system library to use should be specified globally, in a way that try_compile also honors, no? I mean otherwise anything relying on try_compile is broken. For now I simply assume that try_compile get's the same library add_executable or whatever would also get, so the results of try_compile will be whatever the user can use. 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] Please review CXXFeatures.cmake
Am Sonntag, 28. April 2013, 13:57:26 schrieb Rolf Eike Beer: One question I see increasingly often is how do I test for C++11 support or for specific parts of that. For 2.8.12 I plan to include the check module I wrote for that a while back, and that I have reworked in the last weeks. You can find the current state in the rework branch of this repository: Ok, I finally put it into the CMake repository: http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=8ea3dcd28d290f5eb15ab2caeab1ca925dd8c136 Brad, please don't merge that next week as I first want to get some more expected compiler results squashed into that. And of course sort out why it is failing at the dashboards. 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] Please review CXXFeatures.cmake
Alexander Neundorf wrote: On Friday 19 July 2013, Rolf Eike Beer wrote: Ok, I've pushed an updated version to the rework branch. A test for the component check is missing, but all of your other suggestions should have been addressed. The variable is case-sensitive, so it is CXXFeatures_FIND_COMPONENTS, not CXXFEATURES_FIND_COMPONENTS. Fixed. I'm not sure I would have made this a find-module, instead of a simple module which can be included and then provides a function, but I think this doesn't matter much. Because I get things like components for free then ;) And of course, before merging into cmake, the cmake_minimum_required() call can be removed. Yes, and some other minor things. I have a list somewhere, probably on my other machine. 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] Please review CXXFeatures.cmake
On Friday 19 July 2013, Rolf Eike Beer wrote: Alexander Neundorf wrote: On Monday 29 April 2013, Rolf Eike Beer wrote: Alexander Neundorf wrote: On Sunday 28 April 2013, Rolf Eike Beer wrote: One question I see increasingly often is how do I test for C++11 support or for specific parts of that. For 2.8.12 I plan to include the check module I wrote for that a while back, and that I have reworked in the last weeks. You can find the current state in the rework branch of this repository: git://anongit.kde.org/scratch/dakon/cmake-cxx11 Is the try_run() in all cases necessary ? It would be better if a try_compile() would suffice, that's faster and then it works the same way when cross-compiling and when not. I'm not sure about this, but the other ones I consider real bugs. Thanks for catching them, will fix soon. is this in master in the meantime ? I can't find it, or has it been renamed ? Ok, I've pushed an updated version to the rework branch. A test for the component check is missing, but all of your other suggestions should have been addressed. The variable is case-sensitive, so it is CXXFeatures_FIND_COMPONENTS, not CXXFEATURES_FIND_COMPONENTS. I'm not sure I would have made this a find-module, instead of a simple module which can be included and then provides a function, but I think this doesn't matter much. And of course, before merging into cmake, the cmake_minimum_required() call can be removed. Alex -- 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] Please review CXXFeatures.cmake
Rolf Eike Beer wrote: Ok, I've pushed an updated version to the rework branch. A test for the component check is missing, but all of your other suggestions should have been addressed. Has anyone anything else, otherwise I will o and put this into CMake next once I have the test. Do you have any response to the issue from Thiago here? http://thread.gmane.org/gmane.comp.kde.devel.core/80156/focus=80172 The header generated by your module would have to be installed, right? Otherwise it would make more sense to just use 'override' directly. The generated header is specific to whatever compiler was used when cmake generated it. 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] Please review CXXFeatures.cmake
Stephen Kelly wrote: Rolf Eike Beer wrote: Ok, I've pushed an updated version to the rework branch. A test for the component check is missing, but all of your other suggestions should have been addressed. Has anyone anything else, otherwise I will o and put this into CMake next once I have the test. Do you have any response to the issue from Thiago here? http://thread.gmane.org/gmane.comp.kde.devel.core/80156/focus=80172 The header generated by your module would have to be installed, right? Otherwise it would make more sense to just use 'override' directly. The generated header is specific to whatever compiler was used when cmake generated it. I don't generate a header. What I proposed there was to return a list of compat definitions. But those will for reasons said e.g. by Michael Pyne not include a definition for override. Currently there is no such list generated at all. What it indeed could include would be -D nullptr=0 and -D static_assert(x, y)= or the proper, compiler dependent form of those. 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] Please review CXXFeatures.cmake
Alexander Neundorf wrote: On Monday 29 April 2013, Rolf Eike Beer wrote: Alexander Neundorf wrote: On Sunday 28 April 2013, Rolf Eike Beer wrote: One question I see increasingly often is how do I test for C++11 support or for specific parts of that. For 2.8.12 I plan to include the check module I wrote for that a while back, and that I have reworked in the last weeks. You can find the current state in the rework branch of this repository: git://anongit.kde.org/scratch/dakon/cmake-cxx11 Is the try_run() in all cases necessary ? It would be better if a try_compile() would suffice, that's faster and then it works the same way when cross-compiling and when not. I'm not sure about this, but the other ones I consider real bugs. Thanks for catching them, will fix soon. is this in master in the meantime ? I can't find it, or has it been renamed ? Ok, I've pushed an updated version to the rework branch. A test for the component check is missing, but all of your other suggestions should have been addressed. Has anyone anything else, otherwise I will o and put this into CMake next once I have the test. 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] Please review CXXFeatures.cmake
On Monday 29 April 2013, Rolf Eike Beer wrote: Alexander Neundorf wrote: On Sunday 28 April 2013, Rolf Eike Beer wrote: One question I see increasingly often is how do I test for C++11 support or for specific parts of that. For 2.8.12 I plan to include the check module I wrote for that a while back, and that I have reworked in the last weeks. You can find the current state in the rework branch of this repository: git://anongit.kde.org/scratch/dakon/cmake-cxx11 Is the try_run() in all cases necessary ? It would be better if a try_compile() would suffice, that's faster and then it works the same way when cross-compiling and when not. I'm not sure about this, but the other ones I consider real bugs. Thanks for catching them, will fix soon. is this in master in the meantime ? I can't find it, or has it been renamed ? Alex -- 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] Please review CXXFeatures.cmake
On Thu Jul 18 21:17:25 2013 Alexander Neundorf neund...@kde.org wrote: On Monday 29 April 2013, Rolf Eike Beer wrote: Alexander Neundorf wrote: On Sunday 28 April 2013, Rolf Eike Beer wrote: One question I see increasingly often is how do I test for C++11 support or for specific parts of that. For 2.8.12 I plan to include the check module I wrote for that a while back, and that I have reworked in the last weeks. You can find the current state in the rework branch of this repository: git://anongit.kde.org/scratch/dakon/cmake-cxx11 Is the try_run() in all cases necessary ? It would be better if a try_compile() would suffice, that's faster and then it works the same way when cross-compiling and when not. I'm not sure about this, but the other ones I consider real bugs. Thanks for catching them, will fix soon. is this in master in the meantime ? I can't find it, or has it been renamed ? Nope, this is still on my list of things to do. Eike -- 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] Please review CXXFeatures.cmake
On Sunday 28 April 2013, Rolf Eike Beer wrote:
One question I see increasingly often is how do I test for C++11 support
or for specific parts of that. For 2.8.12 I plan to include the check
module I wrote for that a while back, and that I have reworked in the last
weeks. You can find the current state in the rework branch of this
repository:
git://anongit.kde.org/scratch/dakon/cmake-cxx11
Line 75: if (CROSS_COMPILING)
Do you mean if(CMAKE_CROSSCOMPILING) ?
Is the try_run() in all cases necessary ?
It would be better if a try_compile() would suffice, that's faster and then it
works the same way when cross-compiling and when not.
Line 139:
if (NOT CXXFEATURES_FIND_COMPONENTS)
set(CXXFEATURES_FIND_COMPONENTS ${_CXX_ALL_FEATURES})
endif ()
foreach (_cxx_feature IN LISTS _CXX_ALL_FEATURES)
cxx_check_feature(${_cxx_feature} ${FEATURE_NAME})
endforeach (_cxx_feature)
Is this how it is supposed to be or should the foreach() loop run over
CXXFEATURES_FIND_COMPONENTS ?
I didn't try, but it seems it can fail if I give an unknown component. Is
there a check that only known components (CXX features) are requested ?
Alex
--
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] Please review CXXFeatures.cmake
Alexander Neundorf wrote: On Sunday 28 April 2013, Rolf Eike Beer wrote: One question I see increasingly often is how do I test for C++11 support or for specific parts of that. For 2.8.12 I plan to include the check module I wrote for that a while back, and that I have reworked in the last weeks. You can find the current state in the rework branch of this repository: git://anongit.kde.org/scratch/dakon/cmake-cxx11 Is the try_run() in all cases necessary ? It would be better if a try_compile() would suffice, that's faster and then it works the same way when cross-compiling and when not. I'm not sure about this, but the other ones I consider real bugs. Thanks for catching them, will fix soon. 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] Please review CXXFeatures.cmake
On Monday 29 April 2013, Rolf Eike Beer wrote: Alexander Neundorf wrote: On Sunday 28 April 2013, Rolf Eike Beer wrote: One question I see increasingly often is how do I test for C++11 support or for specific parts of that. For 2.8.12 I plan to include the check module I wrote for that a while back, and that I have reworked in the last weeks. You can find the current state in the rework branch of this repository: git://anongit.kde.org/scratch/dakon/cmake-cxx11 Is the try_run() in all cases necessary ? It would be better if a try_compile() would suffice, that's faster and then it works the same way when cross-compiling and when not. I'm not sure about this, but the other ones I consider real bugs. Thanks for catching them, will fix soon. Or IOW: if possible at all, try really hard to get away with only try_compile(), i.e. avoid try_run(). Alex -- 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
[cmake-developers] Please review CXXFeatures.cmake
One question I see increasingly often is how do I test for C++11 support or for specific parts of that. For 2.8.12 I plan to include the check module I wrote for that a while back, and that I have reworked in the last weeks. You can find the current state in the rework branch of this repository: git://anongit.kde.org/scratch/dakon/cmake-cxx11 I renamed the module to CXXFeatures because after all it is not specific to C++11 at all. C++1y is under construction (may eventually become C++14 or something), and it doesn't make sense to have a new module then again. And this can even be used to check features of older compilers if one writes the modules for it. The module should work with CMake = 2.8.3 for those that want to copy it into their projects and need to support older CMake releases. But since this may still change please make sure that you will pick up the one from 2.8.12 or later if your project releases you do now will be configured by a new CMake in half a year. Greetings, 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
