Re: [cmake-developers] Suspicious Clang versions
s...@rogue-research.com wrote: Yeah, it's confusing... :( http://open.cdash.org/testDetails.php?test=201937899build=2986383 (MacOS 10.7) The CXX compiler identification is Clang 4.0.0 I do not believe that. Apple has their own fork/branch of clang which they use in Xcode. AFAICT it's not so different from the open source one, it's probably more to do with them not wanting to tie Xcode's release schedule to clang's. Anyway, very confusingly, Apple uses their own version numbering scheme. So that's Apple clang 4.0. It comes with whatever version of Xcode that machine's running (4.4 I think?). Wow, this idea is so awesome, they probably should file a patent for it. So any version checking like I do in the CXXFeatures test (I have compiler version X, the supported features should be ...) is entirely mood for Clang. Great. Especially as http://open.cdash.org/testDetails.php?test=201937829build=2986379 (MacOS 10.8) shows 3.4.0. But since even 3.4 does not seem to be released I wonder what's going on there? That one is the open source clang, which I build from svn. It's not from Xcode. It's my 'bleeding edge' build machine. clang is always getting stricter and getting new warnings, so this help us fix them before a CMake/VTK/ITK release. Fine. Why don't they name it 3.3.99 then? ;) 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] Suspicious Clang versions
On 08/05/2013 02:08 AM, Rolf Eike Beer wrote: s...@rogue-research.com wrote: very confusingly, Apple uses their own version numbering scheme. So that's Apple clang 4.0. It comes with whatever version of Xcode that machine's running (4.4 I think?). any version checking like I do in the CXXFeatures test is entirely mood for Clang. We need to fix this somehow or CMAKE_*_COMPILER_VERSION will be useless for Clang. Sean, is there any way to extract the underlying Clang version, perhaps with different preprocessor macros? We at least need to be able to detect which version scheme is in use so we can report it somehow. 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
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] Suspicious Clang versions
On 08/05/2013 09:26 AM, Stephen Kelly wrote: Brad King wrote: We need to fix this somehow or CMAKE_*_COMPILER_VERSION will be useless for Clang. Sean, is there any way to extract the underlying Clang version, perhaps with different preprocessor macros? We at least need to be able to detect which version scheme is in use so we can report it somehow. According to https://developer.apple.com/library/mac/#documentation/porting/conceptual/portingunix/compiling/compiling.html and local testing we can use __APPLE_CC__ to detect Apple compiler builds. This might lead to a solution: https://github.com/mozilla/rust/issues/6419 That shows a difference in the version string reported from the compiler but AFAICT there is no way to determine the based on version from the preprocessor. Also any preprocessor tests in C/C++ code that use __clang_major__ for anything will get incorrect results. It would have to be first conditioned on __APPLE_CC__ to know how to interpret the version number. We could consider treating this as a separate compiler and using a new compiler id like ClangApple or AppleClang or something. -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] Suspicious Clang versions
On Mon, 5 Aug 2013 08:08:20 +0200, Rolf Eike Beer said: So any version checking like I do in the CXXFeatures test (I have compiler version X, the supported features should be ...) is entirely mood for Clang. Great. Well, I don't know what we're really talking about here... but it sounds like you're trying to determine a compiler's features based on its version number. That's inherently pretty fragile, don't you agree? I do know that the clang folks discourage trying to determine clang's abilities from its version number. Instead, they have a mechanism called 'Feature Checking Macros' described here: http://clang.llvm.org/docs/LanguageExtensions.html#feature-checking-macros Cheers, -- Sean McBride, B. Eng s...@rogue-research.com Rogue Researchwww.rogue-research.com Mac Software Developer Montréal, Québec, Canada -- 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] CMake is slow for project with hundred target and one command with large number of dependencies
Hi, I have just rebased my branch on top of the master and the test suite still pass. I have a real world example here with performance. My project's build system has 7113 commands to run. This is roughly 7 commands for each input files. There are 1000 inputs files. Just for the configuration step: cmake latest release takes 59:50.10 minutes cmake with my branch takes 1:06.98 minutes So it is about an hour with the latest release and 1 minutes with the patch. I have updated the code, so I hope it will be clearer now. I really want to have this patch in the next release, since I cannot use cmake for my project otherwise. I can work full time on this patch until the end of this week if there is something to change. Cheers, -Nico On Mon, Jul 29, 2013 at 2:40 PM, Nicolas Desprès nicolas.desp...@gmail.comwrote: On Mon, Jul 29, 2013 at 2:25 PM, Stephen Kelly steve...@gmail.com wrote: Nicolas Desprès wrote: Also, I don't see why the custom comparison functor is needed at all. I removed it and sped up the test significantly. Can you explain? I had some failing tests because the previous algorithm was not a plain strcpy(). I don't see any strcpy(). Anyway, I think that's as much useful review I can do for you. I think Brad will have to do the rest. Arg. Sorry for being unclear (English is not my mother tongue). The std::lessstring comparator do the same thing (as strcpy() 0). Unfortunately, we cannot use it here because the previous (O(N)) implementation of cmMakefile::GetSourceFileWithOutput(const char*) was more complex than that (have a look to the code my path replaces). Of course, I first tried with the default comparator to save me some work but some tests were failing. Namely: ExportImport and CustomCommand. Hope this help. Thanks for your time. -Nico -- Nicolas Desprès -- 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] Suspicious Clang versions
On Mon, 5 Aug 2013 09:44:00 -0400, Brad King said: and local testing we can use __APPLE_CC__ to detect Apple compiler builds. In my own build of open source clang from svn trunk, it seems that __APPLE_CC__ is defined: $ clang -dM -E - /dev/null #define __APPLE_CC__ 5621 So I don't think that will help. We could consider treating this as a separate compiler and using a new compiler id like ClangApple or AppleClang or something. That's probably a good idea... Embarcadero's compiler is also based on clang, how do you deal with it? I guess if the output of 'clang --version' includes the string 'Apple', it's AppleClang and not clang. But I think it may be a good idea to ask on cfe-dev or xcode-users mailing lists too... Cheers, -- Sean McBride, B. Eng s...@rogue-research.com Rogue Researchwww.rogue-research.com Mac Software Developer Montréal, Québec, Canada -- 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] Suspicious Clang versions
Sean McBride wrote: On Mon, 5 Aug 2013 08:08:20 +0200, Rolf Eike Beer said: So any version checking like I do in the CXXFeatures test (I have compiler version X, the supported features should be ...) is entirely mood for Clang. Great. Well, I don't know what we're really talking about here... but it sounds like you're trying to determine a compiler's features based on its version number. That's inherently pretty fragile, don't you agree? I do know that the clang folks discourage trying to determine clang's abilities from its version number. Instead, they have a mechanism called 'Feature Checking Macros' described here: http://clang.llvm.org/docs/LanguageExtensions.html#feature-checking-macros That could be something for both the testcase as well as the feature checks. I'll see if I can come up with a good solution to that. The which feature does match $version is just a testcase thing to see if the module gives the expected results. 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: 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] Suspicious Clang versions
On 08/05/2013 11:33 AM, Sean McBride wrote: In my own build of open source clang from svn trunk, it seems that __APPLE_CC__ is defined: $ clang -dM -E - /dev/null #define __APPLE_CC__ 5621 So I don't think that will help. I also see __apple_build_version__ in that output. Searching for it finds that it is used for this purpose in Qt: https://qt.gitorious.org/qt/qtbase/commit/26c7bb25 but seems to be undocumented in general. Will that work? Embarcadero's compiler is also based on clang, how do you deal with it? We don't support Clang-based Embarcadero compilers yet AFAIK. However, this demonstrates that we will need a compiler id for each vendor that distributes a modified Clang. With a separate compiler id then version comparisons can become meaningful again. -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] Suspicious Clang versions
On 08/05/2013 03:28 PM, Brad King wrote: I also see __apple_build_version__ in that output. Searching for it finds that it is used for this purpose in Qt: https://qt.gitorious.org/qt/qtbase/commit/26c7bb25 but seems to be undocumented in general. Will that work? Embarcadero's compiler is also based on clang, how do you deal with it? We don't support Clang-based Embarcadero compilers yet AFAIK. However, this demonstrates that we will need a compiler id for each vendor that distributes a modified Clang. With a separate compiler id then version comparisons can become meaningful again. One of the main purposes of the compiler id is to load platform modules like Platform/os-id-lang and Compiler/id-lang. Most of the information in these files will be identical across the upstream and vendor-specific Clang distributions so having a separate compiler id may lead to confusion and duplication. Another approach is to introduce a CMAKE_LANG_COMPILER_VENDOR variable to name the vendor (or _VARIANT?). This would allow code that needs to know the difference to detect it but otherwise stay out of the way. Then the order of most granular to least granular compiler identification would be ID VENDOR VERSION. What would we do with compilers where the ID implies the VENDOR, though? Comments? -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] CMake is slow for project with hundred target and one command with large number of dependencies
On 08/05/2013 12:06 PM, Brad King wrote: Here are a couple comments: Also I think the cmMakefile copy constructor needs to be taught about the member you're adding. -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] Suspicious Clang versions
Brad King wrote: On 08/05/2013 02:08 AM, Rolf Eike Beer wrote: s...@rogue-research.com wrote: very confusingly, Apple uses their own version numbering scheme. So that's Apple clang 4.0. It comes with whatever version of Xcode that machine's running (4.4 I think?). any version checking like I do in the CXXFeatures test is entirely mood for Clang. We need to fix this somehow or CMAKE_*_COMPILER_VERSION will be useless for Clang. Sean, is there any way to extract the underlying Clang version, perhaps with different preprocessor macros? We at least need to be able to detect which version scheme is in use so we can report it somehow. http://open.cdash.org/testDetails.php?test=202256403build=2988951 Is that another case? Maybe a clang that is misdetected as gcc? For such an old gcc version it has a whole lot of features that are not really expected to be there. 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] CMake is slow for project with hundred target and one command with large number of dependencies
On Mon, Aug 5, 2013 at 6:06 PM, Brad King brad.k...@kitware.com wrote: On 08/05/2013 11:28 AM, Nicolas Desprès wrote: I have just rebased my branch on top of the master and the test suite still pass. [snip] I really want to have this patch in the next release I can't promise to accept it since 2.8.12 rc1 is coming out tomorrow or Wednesday and this topic isn't even in 'next' yet. This touches some pretty fundamental logic and could easily have a subtle behavior change so I consider it high risk. I understand. I have just found an issue that is not covered by CMake's test suite. It happens when one of the file path is empty. I will add a test for this case tomorrow. On 07/29/2013 08:25 AM, Stephen Kelly wrote: I think Brad will have to do the rest. Sorry, I stopped reading this thread assuming that it would end with Steve bringing the change to the topic stage at which point my attention would be drawn again. No problem. I just fetched the large-deps-perf topic from your Github repo. I've never been happy with the linear search so thanks for working on this. Here are a couple comments: * Please replace large_list.cmake in the test with use of the foreach() command's RANGE signature and list(APPEND). Done. * Why is special logic in Tests/CMakeLists.txt needed to add the test case? Since it is a performance test on configuration phase only, I need a specific timeout value and to run cmake only (neither make, nor any extra program built the test project). I have added a comment saying so. * Please add comments explaining in prose what the lookup map comparison functor is doing and why. I could infer it only by looking at the old code (which should have been commented before too). The assert examples are good for verification but not for understanding from scratch. I added the comment. I hope it is understandable. The best would be to have a unit test for this method but I can't think of a simple way to do it since there will be too many objects to mock. I have pushed a bunch of fixup commit if you want to review them. I will squash them tomorrow. Thanks, -- Nicolas Desprès -- 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] CMake is slow for project with hundred target and one command with large number of dependencies
On Mon, Aug 5, 2013 at 9:50 PM, Brad King brad.k...@kitware.com wrote: On 08/05/2013 12:06 PM, Brad King wrote: Here are a couple comments: Also I think the cmMakefile copy constructor needs to be taught about the member you're adding. Yep I do that tomorrow morning. It is late now in France. -- Nicolas Desprès -- 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] CMake is slow for project with hundred target and one command with large number of dependencies
On 08/05/2013 04:37 PM, Nicolas Desprès wrote: I have pushed a bunch of fixup commit if you want to review them. I will squash them tomorrow. Thanks! Don't bother squashing yet. There may be more fixups needed after testing. -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] CMake is slow for project with hundred target and one command with large number of dependencies
On 08/05/2013 04:37 PM, Nicolas Desprès wrote: * Why is special logic in Tests/CMakeLists.txt needed to add the test case? Since it is a performance test on configuration phase only, I need a specific timeout value and to run cmake only Take a look at the Tests/RunCMake and Tests/CMakeOnly groups of tests. They are for running CMake without building. -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] Targets for FindGTK2.cmake
Daniele,
Your changes look fine to me although my experience with imported targets
is limited so someone with more experience should review your changes there.
I'm not sure if there is a way to develop automated unit tests and mark
them to not run by default. That would be useful for regression testing of
modules even if it the tests had to be run manually. Would be a good
question for some of the more active developers (read: not me) :).
If compilation of the hello world examples is still working for you, that
would be a pretty good sign you didn't break anything.
https://developer.gnome.org/gtk-tutorial/stable/c39.html#SEC-HELLOWORLD
https://developer.gnome.org/gtkmm-tutorial/2.24/sec-helloworld.html.en
Here's some old test code I had lying around which obviously could be much
improved.
*CMakeLists.txt*
project(foo)
cmake_minimum_required(VERSION 2.6)
set(GTK2_DEBUG TRUE)
set(CMAKE_MODULE_PATH ${CMAKE_CURRENT_SOURCE_DIR})
find_package(GTK2 2.16 REQUIRED gtk glade gtkmm glademm)
message(GTK2_INCLUDE_DIRS = ${GTK2_INCLUDE_DIRS})
message(GTK2_LIBRARIES = ${GTK2_LIBRARIES})
include_directories(${GTK2_INCLUDE_DIRS})
add_executable(bar bar.cc helloworld.cc)
target_link_libraries(bar ${GTK2_LIBRARIES}
*bar.cc:*
#include gtkmm/main.h
#include helloworld.h
int main (int argc, char *argv[])
{
Gtk::Main kit(argc, argv);
HelloWorld helloworld;
//Shows the window and returns when it is closed.
Gtk::Main::run(helloworld);
return 0;
}
*helloworld.cc*
#include helloworld.h
#include iostream
HelloWorld::HelloWorld()
: m_button(Hello World) // creates a new button with label Hello
World.
{
// Sets the border width of the window.
set_border_width(10);
// When the button receives the clicked signal, it will call the
// on_button_clicked() method defined below.
m_button.signal_clicked().connect(sigc::mem_fun(*this,
HelloWorld::on_button_clicked));
// This packs the button into the Window (a container).
add(m_button);
// The final step is to display this newly created widget...
m_button.show();
}
HelloWorld::~HelloWorld()
{
}
void HelloWorld::on_button_clicked()
{
std::cout Hello World std::endl;
}
*helloworld.h*
#ifndef GTKMM_EXAMPLE_HELLOWORLD_H
#define GTKMM_EXAMPLE_HELLOWORLD_H
#include gtkmm/button.h
#include gtkmm/window.h
class HelloWorld : public Gtk::Window
{
public:
HelloWorld();
virtual ~HelloWorld();
protected:
//Signal handlers:
void on_button_clicked();
//Member widgets:
Gtk::Button m_button;
};
#endif // GTKMM_EXAMPLE_HELLOWORLD_H
On Mon, Aug 5, 2013 at 11:00 AM, Daniele E. Domenichelli
daniele.domeniche...@gmail.com wrote:
Hello all,
I'd like to introduce imported targets in FindGTK2.cmake, in a similar
manner as they are used in FindQT4.cmake.
The aim is to be able to do something like:
find_package(GTK2 gtk gtkmm)
target_link_libraries(target GTK2::gtkmm)
(In the future I want to handle dependencies on modules as well, at the
moment I think that if you don't include the gtk module it will not work)
If you want to review my changes, you can checkout the FindGTK2-targets
topic. I tested it on Windows and Linux, but unfortunately there are not
unit tests afaik.
Cheers,
Daniele
--
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
--
Philip Lowman
--
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
