[cmake-developers] Setting unexposed Visual Studio properties from CMake?
Hi, Is there a way to set unexposed Visual Studio properties from CMake? In XCode generator, we have XCODE_ATTRIBUTE_an-attribute. What about Visual Studio? The reason we need this is because we are trying to set project properties of the Nsight Tegra Android generator that are not exposed to CMake. Exposing every single Nsight Tegra build options to CMake is a big job, and perhaps a similar option like XCode would be beneficial to other generators as well. If it's not available, how difficult would it be to add this feature? Thanks! -Robert Goulet -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
[cmake-developers] [CMake 0015448]: find_path() after mark_as_advanced()
The following issue has been SUBMITTED.
==
http://www.cmake.org/Bug/view.php?id=15448
==
Reported By:nagger
Assigned To:
==
Project:CMake
Issue ID: 15448
Category: CMake
Reproducibility:always
Severity: minor
Priority: normal
Status: new
==
Date Submitted: 2015-03-16 14:32 CET
Last Modified: 2015-03-16 14:32 CET
==
Summary:find_path() after mark_as_advanced()
Description:
It not clear to me if the following is a bug in CMake or just an invalid use:
(I tested this for CMake 2.8.11, 3.0.1 and 3.2.1.)
set(my_path anyvalue)
find_path(my_path NAMES CMakeLists.txt HINTS ${CMAKE_CURRENT_LIST_DIR})
mark_as_advanced(my_path)
find_path(my_path NAMES CMakeLists.txt HINTS ${CMAKE_CURRENT_LIST_DIR})
message(my_path: '${my_path}') # my_path is empty here!
1st FIND_PATH() uses only the non-cached variable and does not create the
cache-variable
* this is not described in the docs
** the docs should also describe when and how the cached-variable and the
non-cached variable is read and written
** same goes for all find_*-commands
MARK_AS_ADVANCED() for an undefined cache-variable creates the cache-var with
and empty value and type 'UNDEFINED'
* Is this a bug(?)
* It could use the value of the non-cached variable (if there is one)
* or it should not set the VALUE-property of the cached variable
* or set the type to 'STRING'
The 2nd FIND_PATH() does not use the non-cached variable as in the first call,
but clears the variable without search for the path
* For me this looks like a bug!
Steps to Reproduce:
See attached self-contained CMakeLists.txt with a lot of test cases (T1 .. T8)
and its output at the end of the file.
For me T1 and T2 is a bug, at least it should act as in T5 or in T7.
And T9 also seems like a bug since the docs say:
[...] the search will not be repeated unless the variable is cleared
And T8 is inconsistent to the other tests: Its overwriting the cached value
although the variable is set.
Until now I thought that the cached value is always overwritten with the value
of the variable. Is there any reason why it is not?
==
Issue History
Date ModifiedUsername FieldChange
==
2015-03-16 14:32 nagger New Issue
==
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Extracting target metadata, IDE integration
On Sun, Mar 15, 2015 at 6:17 PM, Peter Kümmel syntheti...@gmx.net wrote: The idea was that qtcreator then also could parse and change the CMakeLists.txt file (like it is done with qbs files, I assume). That would be a nice to have feature, yes, but I doubt that this will ever be an option with cmake. And I personally do not want to pile anything on top of cmake to enable this for a small subset of still-to-be-written projects. I would like to get to the point where you are able to build cmake projects, configure them and have creator open the correct CMakeLists.txt for you when you need to add/remove files to/from some target. It will need work in Creator to get there, and I really do not want that to end up relying on what I consider to be a implementation detail of cmake -- like the format of (probably even undocumented) files somewhere in the build directory that were meant for other consumers. This JSON file can be a step forward here: It is actually meant to be used by IDEs, it has a format straight forward to parse, it does not depend on the generator used, it will (hopefully;-) end up being documented, it provides versioning, etc. I see some potential there. Best Regards, Tobias -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Introduction and volunteering for the Matlab package
Le 12/03/15 21:00, Brad King a écrit : On 03/12/2015 12:35 PM, Raffi Enficiaud wrote: * Renamed one more MATLAB_USER_ROOT = Matlab_ROOT_DIR * Do not call list(REMOVE_DUPLICATES/SORT/REVERSE) with no list Thanks! The commits are now: FindMatlab: Rewrite module and provide a usage API http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=3c025a5f FindMatlab: Further revisions http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=842ab109 FindMatlab: Further revisions http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=3743aa11 I will squash all this together once everything is done. For now please base further work on commit 3743aa11. We'll see how this does on the nightly testing! A test is failing on win32 but I to not think it is due to the FindMatlab: https://open.cdash.org/testDetails.php?test=319823202build=3731585 What other changes are needed? Best, Raffi -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] FW: FW: Initial Attempt at Green Hill MULTI IDE Generator Support
In Modules/Platform/GHS-MULTI-Initialize.cmake:
+#Setup consistent compiler executables
+find_program(CMAKE_GENERATOR_CC ccarm PATHS ${GHS_COMP_ROOT})
+find_program(CMAKE_GENERATOR_CXX cxarm PATHS ${GHS_COMP_ROOT})
Removed
+string(REGEX MATCH (comp_)([0-9]+) CMAKE_SYSTEM_VERSION
+${CMAKE_MAKE_PROGRAM}) string(REPLACE comp_
+CMAKE_SYSTEM_VERSION ${CMAKE_SYSTEM_VERSION})
EnableLanguage should be able to set CMAKE_SYSTEM_VERSION too now that it has
code to find the comp root.
Done
+mark_as_advanced(CMAKE_MAKE_PROGRAM)
This should not be needed.
Removed
+include(Platform/WindowsPaths)
This should move to Modules/Platform/GHS-MULTI.cmake
Moved
In EnableLanguage:
+ mf-AddDefinition(CMAKE_MAKE_PROGRAM,
+std::string(ghsCompRootStart +
+ gbuild.exe).c_str());
The VS and Xcode generators no longer put this in the cache.
Take a look at how the Xcode generator now does this with
cmGlobalXCodeGenerator::FindMakeProgram
cmGlobalXCodeGenerator::GetXcodeBuildCommand
cmGlobalXCodeGenerator::FindXcodeBuildCommand
and its call to SelectMakeProgram in GenerateBuildCommand:
this-SelectMakeProgram(makeProgram, this-GetXcodeBuildCommand())
Together this all allows the generator to compute the proper build tool
without exposing any settings to the user.
Moved
+ mf-AddDefinition(CMAKE_C_COMPILER_ID, GhsMultiArmC);
[snip]
+ mf-AddDefinition(CMAKE_CXX_COMPILER_ID, GhsMultiArmCXX);
Instead of GhsMultiArm* these should be just GHS, to be consistent with
Modules/Compiler/GHS-DetermineCompiler.cmake.
Renamed
Please also look at modifying the Help/ directory to document the new
generator. You'll need at least to create/update:
Help/manual/cmake-generators.7.rst
Help/generator/Green Hills MULTI.rst
Help/variable/CMAKE_MAKE_PROGRAM.rst
where the change to the last one depends on the above updates.
Added some documentation.
I reran the experimental tests:
https://open.cdash.org/viewTest.php?onlyfailedbuildid=3731770. I'm not quite
sure why my FindModulesExecuteAll test fails. Seems like boost installation
issue, but it isn't an issue in my nighlty test:
https://open.cdash.org/testDetails.php?test=319857216build=3731770.
Geoffrey Viola
SOFTWARE ENGINEER
asirobots.com
-Original Message-
From: Brad King [mailto:brad.k...@kitware.com]
Sent: Thursday, March 12, 2015 2:18 PM
To: Geoffrey Viola
Cc: cmake-developers@cmake.org
Subject: Re: FW: FW: [cmake-developers] Initial Attempt at Green Hill MULTI IDE
Generator Support
On 03/11/2015 01:39 PM, Geoffrey Viola wrote:
Attached is a patch with the recommended changes
Thanks! The basic toolchain initialization is pretty close.
Here are more comments.
In Modules/Platform/GHS-MULTI-Initialize.cmake:
+#Setup consistent compiler executables
+find_program(CMAKE_GENERATOR_CC ccarm PATHS ${GHS_COMP_ROOT})
+find_program(CMAKE_GENERATOR_CXX cxarm PATHS ${GHS_COMP_ROOT})
This should not be needed at all. The CMAKE_GENERATOR_* variables are just
hints to the compiler detection logic. Since this generator hard-codes the
compiler setting in C++ the logic that uses these variables is never executed
anyway.
+string(REGEX MATCH (comp_)([0-9]+) CMAKE_SYSTEM_VERSION
+${CMAKE_MAKE_PROGRAM}) string(REPLACE comp_
+CMAKE_SYSTEM_VERSION ${CMAKE_SYSTEM_VERSION})
EnableLanguage should be able to set CMAKE_SYSTEM_VERSION too now that it has
code to find the comp root.
+mark_as_advanced(CMAKE_MAKE_PROGRAM)
This should not be needed.
+include(Platform/WindowsPaths)
This should move to Modules/Platform/GHS-MULTI.cmake
In EnableLanguage:
+ mf-AddDefinition(CMAKE_MAKE_PROGRAM,
+std::string(ghsCompRootStart +
+ gbuild.exe).c_str());
The VS and Xcode generators no longer put this in the cache.
Take a look at how the Xcode generator now does this with
cmGlobalXCodeGenerator::FindMakeProgram
cmGlobalXCodeGenerator::GetXcodeBuildCommand
cmGlobalXCodeGenerator::FindXcodeBuildCommand
and its call to SelectMakeProgram in GenerateBuildCommand:
this-SelectMakeProgram(makeProgram, this-GetXcodeBuildCommand())
Together this all allows the generator to compute the proper build tool without
exposing any settings to the user.
+ mf-AddDefinition(CMAKE_C_COMPILER_ID, GhsMultiArmC);
[snip]
+ mf-AddDefinition(CMAKE_CXX_COMPILER_ID, GhsMultiArmCXX);
Instead of GhsMultiArm* these should be just GHS, to be consistent with
Modules/Compiler/GHS-DetermineCompiler.cmake.
-
Please also look at modifying the Help/ directory to document the new
generator. You'll need at least to create/update:
Help/manual/cmake-generators.7.rst
Help/generator/Green Hills MULTI.rst
Help/variable/CMAKE_MAKE_PROGRAM.rst
where the change to the last one depends on the above updates.
Thanks,
-Brad
This message contains confidential information and is intended only for the
recipient. If you are not the named addressee you should not
Re: [cmake-developers] [CMake] Problems with WriteCompilerDetectionHeader and cxx_nullptr
Hi Brad,
attached is an updated patch.
Roman
From ea75cb1a3d866d923b6711c9e0c0bbf1f66d7dbf Mon Sep 17 00:00:00 2001
From: Roman Wüger roman.wue...@gmx.at
Date: Fri, 13 Mar 2015 09:18:19 +0100
Subject: [PATCH] WCDH: Fix cxx_nullptr for compilers which doesn't support
C++11
---
Modules/WriteCompilerDetectionHeader.cmake | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Modules/WriteCompilerDetectionHeader.cmake
b/Modules/WriteCompilerDetectionHeader.cmake
index d18f47c..f4dcb21 100644
--- a/Modules/WriteCompilerDetectionHeader.cmake
+++ b/Modules/WriteCompilerDetectionHeader.cmake
@@ -586,7 +586,7 @@ function(write_compiler_detection_header
# if ${def_name}
#define ${def_value} nullptr
# else
-#define ${def_value} static_castvoid*(0)
+#define ${def_value} 0
# endif
\n)
endif()
--
1.9.5.msysgit.0
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Extracting target metadata, IDE integration
Tobias Hunger wrote: This JSON file can be a step forward here: It is actually meant to be used by IDEs, it has a format straight forward to parse, it does not depend on the generator used, it will (hopefully;-) end up being documented, it provides versioning, etc. I see some potential there. I asked for this thread to be discontinued. I provided a patch which has documentation. There is no 'hopefully' to it. You're simply responding to the wrong thread. Thanks, Steve. -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
[cmake-developers] [CMake 0015449]: Add a TARGET_INFO generator expression
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=15449 == Reported By:Stephen Kelly Assigned To: == Project:CMake Issue ID: 15449 Category: CMake Reproducibility:have not tried Severity: feature Priority: normal Status: new == Date Submitted: 2015-03-16 19:47 CET Last Modified: 2015-03-16 19:47 CET == Summary:Add a TARGET_INFO generator expression Description: Add interface for generating information about various aspects of the build. Possibly add WITH expression for generating information about 'other' configs/platforms etc. == Issue History Date ModifiedUsername FieldChange == 2015-03-16 19:47 Stephen Kelly New Issue 2015-03-16 19:47 Stephen Kelly File Added: 0001-Add-TARGET_INFO-genex.patch == -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Generating buildsystem metadata from CMake
Aleix Pol wrote: By 'in scope' you mean 'used by the primary CMakeLists.txt files via include() or find_package()' or something like that? OK, let's see if that's the best source of that data or if we should add something new internally in cmake. By in scope I mean whether a variable or a target defined in such files. I see. [4] Because cmake is really slow and you often want to have the metadata file updated often, every time one of the cmake files in the project change. OK, maybe we can add something for that, but is it the generation stage that is the slow part? How much time would we gain by doing this? Well, I'm unsure what's the best way to go about it. I understand that given the json file will be executed after all the processing of the sources it won't help much if we just skip the generation. Also maybe it's possible to optimize the configure process all together. Yes, if a 'metadata only' mode can be shown to make sense, it can be added in the future. Thanks, Steve. -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Generating buildsystem metadata from CMake
Nils Gladitz wrote: On 03/11/2015 11:10 AM, Stephen Kelly wrote: I'm starting to gather requirements and make sure the feature is well designed to satisfy the needs we're already aware of, and fits with the features CMake currently has. Source file groups (as in defined by source_group()) and target folders (as in the FOLDER target property) may be of interest to IDEs to layout target and source file hierarchies. Indeed. I don't have enough experience with VS to comment much on this. I've added a commit containing some todos and added it there. Thanks, Steve. -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
