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
[cmake-developers] FindGTK2-quiet topic
On 08/09/2013 10:56 AM, Daniele E. Domenichelli wrote:
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=1e18051f687836052479b70f28c520a5e0626dd7
FindGTK2: Search for modules quietly when needed
[snip]
+set(GTK2_${_COMPONENT_UPPER}_FIND_QUIETLY GTK2_FIND_QUIETLY)
Shouldn't that be
set(GTK2_${_COMPONENT_UPPER}_FIND_QUIETLY ${GTK2_FIND_QUIETLY})
?
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
[cmake-developers] [CMake 0014378]: ZERO_CHECK.vcxproj referenced despite CMAKE_SUPPRESS_REGENERATION set to FALSE
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=14378
==
Reported By:Mateusz Loskot
Assigned To:
==
Project:CMake
Issue ID: 14378
Category: CMake
Reproducibility:always
Severity: minor
Priority: normal
Status: new
==
Date Submitted: 2013-08-27 10:58 EDT
Last Modified: 2013-08-27 10:58 EDT
==
Summary:ZERO_CHECK.vcxproj referenced despite
CMAKE_SUPPRESS_REGENERATION set to FALSE
Description:
I have a collection of predefined .vcxproj files and I use CMake to generate
.sln file gathering all the projects.
In my CMakeLists.txt I set CMAKE_SUPPRESS_REGENERATION to FALSE to prevent
generating of ZERO_CHECK.vcxproj, but GUID of the ZERO_CHECK is still
referenced.
It is, the generated .sln file still gets this postProject section generated
Project({8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}) = cmake_test,
cmake_test.vcxproj, {A4C50E61-87B4-44A9-975E-CDC1649CB0DC}
ProjectSection(ProjectDependencies) = postProject
{AB7E8FC6-757B-400A-AC2A-E4192A4C124E} =
{AB7E8FC6-757B-400A-AC2A-E4192A4C124E}
EndProjectSection
EndProject
where cmake_test is predefiend (not generated) project and
AB7E8FC6-757B-400A-AC2A-E4192A4C124E is GUID of non-existent ZERO_CHECK project.
Steps to Reproduce:
1. Create Win32 Console Application using VS IDE (name used below: cmake_test)
2. Create CMakeLists.txt file:
cmake_minimum_required(VERSION 2.8)
project(cmake_test_gen NONE)
set(CMAKE_SUPPRESS_REGENERATION TRUE)
include_external_msproject(cmake_test cmake_test.vcxproj)
3. Try to build using the generated .sln file:
msbuild cmake_test_gen.sln
Microsoft (R) Build Engine version 4.0.30319.17929
[Microsoft .NET Framework, version 4.0.30319.18052]
Copyright (C) Microsoft Corporation. All rights reserved.
Building the projects in this solution one at a time. To enable parallel build,
please add the /m switch.
Build started 27/08/2013 15:46:41.
D:\tmp\cmake_test\cmake_test_gen.sln : Solution file error MSB4051: Project
{A4C50E61-87B4-44A9-975E-CDC1649CB0DC} is referencing
a project with GUID {AB7E8FC6-757B-400A-AC2A-E4192A4C124E}, but a project with
this GUID was not found in the .SLN file.
Build FAILED.
D:\tmp\cmake_test\cmake_test_gen.sln : Solution file error MSB4051: Project
{A4C50E61-87B4-44A9-975E-CDC1649CB0DC} is referenci
ng a project with GUID {AB7E8FC6-757B-400A-AC2A-E4192A4C124E}, but a project
with this GUID was not found in the .SLN file.
0 Warning(s)
1 Error(s)
Time Elapsed 00:00:00.02
D:\tmp\cmake_test
4. Remove set(CMAKE_SUPPRESS_REGENERATION TRUE) from CMakeLists.txt
5. Re-generate the .sln file and re-build
cmake .
msbuild cmake_test_gen.sln
Observe the build in step 5 succeeds.
Additional Information:
I use Visual Studio 2012.
==
Issue History
Date ModifiedUsername FieldChange
==
2013-08-27 10:58 Mateusz Loskot New Issue
==
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] c++ feature detection and usage requirements (was: Please review CXXFeatures.cmake)
On 08/15/2013 08:37 AM, Stephen Kelly wrote: target_compiler_feature(target PUBLIC|PRIVATE REQUIRED feature1 [feature2 ...]) target_compiler_feature(target PUBLIC|PRIVATE OPTIONAL feature DEFINE define_name) Doesn't this require the language (CXX) to be specified somewhere? Perhaps the feature names should start with lang_ e.g. CXX_final. 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? The detection of features available for a given compiler and the usage requirements to require/enable them are orthogonal issues on the implementation side but may overlap in the CMake interface. I like your proposed target_compiler_feature feature for the latter. As for detection, I like that Eike's solution will work without hard-coding knowledge for every compiler. I also like hard-coding the answers for known compilers whose id/version can be reliably detected to avoid needless try_compile calls on every project. Furthermore, your argument about partial implementations of features versus the documented later version introducing them is important. It is also nice to have it builtin to the platform information modules for use with target_compiler_feature. I'd like to see a solution that hard-codes the answers when known but also knows when it does not know and can run a detection step. This will be tricky because the platform files are too early to use try_compile so some kind of on-demand check may be needed. Ideas? I think Eike's topic will be a fantastic reference for the test case code and the expected results and will be useful for you to write a more complete solution. I like the target_compiler_feature syntax better than find_package(CXXFeatures), but something like the latter may be needed to make CMake-time decisions based on available features rather than waiting until preprocessing time. -Brad -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] c++ feature detection and usage requirements
Brad King wrote:
On 08/15/2013 08:37 AM, Stephen Kelly wrote:
target_compiler_feature(target PUBLIC|PRIVATE
REQUIRED feature1 [feature2 ...])
target_compiler_feature(target PUBLIC|PRIVATE
OPTIONAL feature DEFINE define_name)
Doesn't this require the language (CXX) to be specified somewhere?
Perhaps the feature names should start with lang_ e.g. CXX_final.
I considered that, and I considered adding LANG lang to the command
signatures, and I considered naming the command with the language
(target_cxx_compiler_feature).
I didn't pick one, partly because it's a relatively minor detail we can
decide on after the larger issues below are resolved.
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?
The detection of features available for a given compiler and the
usage requirements to require/enable them are orthogonal issues
on the implementation side but may overlap in the CMake interface.
Yes. Even if we ignore the usage requirements angle, there are enough
reasons to not accept the currently proposed interface in the topic though.
I like your proposed target_compiler_feature feature for the latter.
Great.
As for detection, I like that Eike's solution will work without
hard-coding knowledge for every compiler. I also like hard-coding
the answers for known compilers whose id/version can be reliably
detected to avoid needless try_compile calls on every project.
Yes.
Furthermore, your argument about partial implementations of features
versus the documented later version introducing them is important.
Yes.
It is also nice to have it builtin to the platform information
modules for use with target_compiler_feature. I'd like to see a
solution that hard-codes the answers when known but also knows when
it does not know and can run a detection step.
Yes.
This will be tricky
because the platform files are too early to use try_compile so some
kind of on-demand check may be needed. Ideas?
That should be easy. Encode them into the platform files where known, and
implement target_compiler_feature to run a detection if
CMAKE_CXX_COMPILER_FEATURES is not set.
I think Eike's topic will be a fantastic reference for the test
case code
I agree that Tests/Module/FindCXXFeatures/CMakeLists.txt is a useful
reference. However, I don't think the interface in the topic should be
merged into master. We agree that target_compiler_feature is a better
interface, and hopefully Eike does too.
Eikes interface has some problems which I noted before here which make it
useless for libraries (or at least too incomplete to be useful) because the
result of the feature tests can't be used in public header files:
http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/6726/focus=7715
Additionally, there is a 'cross platform trap' in the topic as it is
currently. Someone implementing a project on Windows using MSVC might write
this (assuming they were creating an executable, not a library because of
the above problem):
find_package(CXXFeatures)
if (CXXFeatures_class_override_final_FOUND)
add_definitions(-DGrantlee_FINAL=final)
endif()
It looks cross-platform, but it is not.
When they port the code to GCC, they need to add the ${CXX11_COMPILER_FLAGS}
somewhere (using the modern add_compile_options? No, using CMAKE_CXX_FLAGS
because it is _FLAGS).
My proposed interface does not have that problem because adding the compile
option for -std=c++11 (or -std=c++1y) is set internally.
As you said though, the detection code and the detection results encoded
into the tests are orthogonal to the interface issues. I think those parts
should be kept and refactored.
I don't think the topic should be merged as-is because of the problems with
the interface we know about so far. If you merge it and we also merge the
interface which we agree to be better, we'll have two competing interfaces.
and the expected results and will be useful for you to
write a more complete solution.
I'm sure Eike can do it too. Or at least get started with encoding the
detection results into platform files and refactoring the detection code out
of the find module so it can be used from the command.
I like the target_compiler_feature
syntax better than find_package(CXXFeatures), but something like the
latter may be needed to make CMake-time decisions based on available
features rather than waiting until preprocessing time.
Users could do the same as I suggest the target_compiler_feature does:
if (CMAKE_CXX_COMPILER_FEATURES)
list(FIND CMAKE_CXX_COMPILER_FEATURES final idx)
if(idx EQUAL -1)
set(HAVE_FINAL 0)
else()
set(HAVE_FINAL 1)
endif()
else()
include(DetectCompilerFeature)
detect_compiler_feature(final HAVE_FINAL)
endif()
if(HAVE_FINAL)
# ...
endif()
Or, even better,
include(DetectCompilerFeature)
# Checks
