Re: [cmake-developers] Listing source-tree files encountered (was: Wrapping functions in CMake)
On Wed, Jul 15, 2015 at 9:10 AM, Brad King brad.k...@kitware.com wrote: On 07/09/2015 01:35 PM, Clifford Yapp wrote: 1. First, we need to maintain a list of all files in the source repository that are known to the build system. To do this we maintain a global list of files, define a custom CMAKEFILES command to allow us to manually specify miscellaneous files as known, and override all of the primary target creating commands to add their files to the list (for example, add_executable is passed a list of source files, and all of those files are automatically added to the known files list by the function override of add_executable.) This list is used for both our make-clean-in-src-dir feature and our distcheck build target (which does a number of verification steps using the version control system, the build system and the files-on-filesystem information to make sure the build logic is current.) These days it is the job of version control tools to know what files are part of the source and what files are not. Commands like git clean are then responsible for cleaning out a source tree, not the build system. Maybe we're a bit retro, but we've got a system set up which uses the VCS (subversion, in our case) to cross check the build system's awareness of files. We have a number of reasons for this approach, which I can go into if anyone's interested, but the punchline is we've implemented our own distcheck system which has a number of (for our project, at least) important features. CMake is mainly designed for out-of-source builds where nothing in the source tree is touched at all. This makes distclean unnecessary. We support in-source builds for end-user convenience when installing a project from a source tarball, but in general development should always be done with out-of-source builds to keep the source pristine. Agreed, but since historically we've allowed in-src-dir builds (in the dark old days that's actually the only way things worked for us, but that's another story) the decision was made to continue support for them. It just so happened that the system we implemented to support distcheck was also the primary piece needed to make in-src-dir practical, so in the end we opted to support it and one of our distcheck test targets is set up specifically to ensure it keeps working. 1. Have CMake internally maintain a list (or maybe per-command lists for more flexibility) of all files with paths relative to the root source directory that have been observed by add_executable, add_library, add_custom_target, add_subdirectory, and configure_file that can be accessed via CMake variables Many of the source file locations are not actually determined until generate time, so a configuration-time list is not possible to implement reliably in general. Maintaining the list would force source file locations to be finalized too early. Lists that contains a verbatim collection of all path specifiers, regardless of form, that are passed to the various add_* targets would be enough, I think - it'd then be up to our own CMake logic to make sense of it all. I'm not hoping to push our whole in-src-dir/distcheck system into mainstream CMake, just looking for a way to achieve the current result without requiring the built-in-command overrides - I think collecting raw lists of paths supplied to targets is the key piece that is currently driving the command overrides. Would such verbatim transcription lists (un-resolved path specifiers and all) be something that could be provided? Thanks, CY -- 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 0015655]: file(GENERATE) fails of the destination directory doesn't exist
The following issue has been SUBMITTED.
==
http://www.cmake.org/Bug/view.php?id=15655
==
Reported By:James Bigler
Assigned To:
==
Project:CMake
Issue ID: 15655
Category: (No Category)
Reproducibility:always
Severity: minor
Priority: normal
Status: new
==
Date Submitted: 2015-07-15 13:42 EDT
Last Modified: 2015-07-15 13:42 EDT
==
Summary:file(GENERATE) fails of the destination directory
doesn't exist
Description:
I wanted to use file(GENERATE) to create some files in an output build
directory, but these directories don't exist at the time of configure and build
so the command fails. These directories are created during build, though so
CMake knows about them somehow.
set(CMAKE_RUNTIME_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/bin)
file(GENERATE OUTPUT ${CMAKE_RUNTIME_OUTPUT_DIRECTORY}/$CONFIG/test.out
CONTENT Hello, world)
file(WRITE a.cpp int main() { return 0; })
add_executable(a a.cpp)
==
Issue History
Date ModifiedUsername FieldChange
==
2015-07-15 13:42 James Bigler 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] Adding Swift support to CMake
On 7/7/15, Brad King brad.k...@kitware.com wrote: On 07/02/2015 07:54 PM, Eric Wing wrote: Thank you Brad. When you are ready, let me know how I can help next. I have basic support with the Xcode generator done. Please try out this commit: Add rudimentary support for the Apple Swift language with Xcode http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=bf112531 Thanks, -Brad Hi Brad, I just tried out the July 15th nightly build and it looks like it is working (Xcode generator). I got a little fancy and did an intermixed C/Swift test. I have a simple SDL (C) based program with Swift bindings and I'm able to build/run it and step the Xcode debugger through the Swift parts. Cosmetically, the Swift files are not being grouped with the other C/Obj-C files in the Source Files group. But that is a pretty minor thing. (There are other things more important to me I would like to see fixed in the Xcode generator first :)) So is the next step the Makefile generator? Thanks, Eric -- 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 0015652]: get_target_property() called with non-existent target boost_chrono-mt-shared
The following issue has been DELETED. == Reported By:Mathieu Malaterre Assigned To: == Project:CMake Issue ID: 15652 Category: CMake Reproducibility:have not tried Severity: minor Priority: normal Status: new == Date Submitted: 2015-07-15 08:28 EDT Last Modified: 2015-07-15 08:28 EDT == Summary:get_target_property() called with non-existent target boost_chrono-mt-shared Description: I cannot use FindBoost.cmake on CentOS6 (boost 1.41), it fails with: CMake Error at /usr/lib64/boost/BoostConfig.cmake:64 (get_target_property): get_target_property() called with non-existent target boost_chrono-mt-shared. Call Stack (most recent call first): /opt/tools/cmake-3.0.1/share/cmake-3.0/Modules/FindBoost.cmake:206 (find_package) CMakeLists.txt:33 (find_package) CMake Error at /usr/lib64/boost/BoostConfig.cmake:72 (get_target_property): get_target_property() called with non-existent target boost_chrono-mt-shared-debug. Call Stack (most recent call first): /opt/tools/cmake-3.0.1/share/cmake-3.0/Modules/FindBoost.cmake:206 (find_package) CMakeLists.txt:33 (find_package) Boost 1.41 found. == Issue History Date ModifiedUsername FieldChange == 2015-07-15 08:28 Mathieu MalaterreNew Issue 2015-07-15 08:30 Mathieu MalaterreIssue Deleted: 0015652 == -- 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] [PATCH] CMakeExpandImportedTargets: use INTERFACE_LINK_LIBRARIES if non-empty
I've just read the discussion at
http://www.cmake.org/Bug/view.php?id=15299 about
the deprecation of CMakeExpandImportedTargets. I guess it means no fixes to
it.
I'm checking BundleUtilities as suggested there.
Tamas
On Wed, Jul 15, 2015 at 5:56 PM, Tamás Kenéz tamas.ke...@gmail.com wrote:
The CMakeExpandedImportedTargets module used only the deprecated
IMPORTED_LINK_INTERFACE_LIBRARIES property to resolve transitive
dependencies.
Since the current `install(EXPORT ...)` command generates target files
that populate INTERFACE_LINK_LIBRARIES instead, the expand module was not
working correctly with the imported libraries generated by `install(EXPORT
...)`.
I considered this a bugfix so I based the commit onto the release branch.
Please review and apply if it's ok.
Tamas
From f2df88ec4180595a3fcc4c6be9b2d38e46162cc3 Mon Sep 17 00:00:00 2001
From: Tamas Kenez tamas.ke...@gmail.com
Date: Wed, 15 Jul 2015 17:47:50 +0200
Subject: [PATCH] CMakeExpandImportedTargets: use INTERFACE_LINK_LIBRARIES
if
non-empty
The deprecated IMPORTED_LINK_INTERFACE_LIBRARIES should be
overridden by INTERFACE_LINK_LIBRARIES if it's non-empty.
Unlike IMPORTED_LINK_INTERFACE_LIBRARIES, INTERFACE_LINK_LIBRARIES
usually contains config-related generator expressions which must
be resolved according to the selected configuration.
---
Modules/CMakeExpandImportedTargets.cmake | 22 +-
1 file changed, 21 insertions(+), 1 deletion(-)
diff --git a/Modules/CMakeExpandImportedTargets.cmake
b/Modules/CMakeExpandImportedTargets.cmake
index 8ac3364..b110e51 100644
--- a/Modules/CMakeExpandImportedTargets.cmake
+++ b/Modules/CMakeExpandImportedTargets.cmake
@@ -102,7 +102,27 @@ function(CMAKE_EXPAND_IMPORTED_TARGETS _RESULT )
list(GET _importedConfigs ${_configIndexToUse}
_importedConfigToUse)
get_target_property(_importedLocation ${_CURRENT_LIB}
IMPORTED_LOCATION_${_importedConfigToUse})
-get_target_property(_linkInterfaceLibs ${_CURRENT_LIB}
IMPORTED_LINK_INTERFACE_LIBRARIES_${_importedConfigToUse} )
+get_target_property(_linkInterfaceLibs ${_CURRENT_LIB}
INTERFACE_LINK_LIBRARIES)
+if(_linkInterfaceLibs)
+ # resolve $CONFIG:... generator expressions
+ string(REGEX REPLACE \\$CONFIG:${_importedConfigToUse}
1
+ _linkInterfaceLibs ${_linkInterfaceLibs})
+ string(REGEX REPLACE \\$CONFIG:[^]* 0
+ _linkInterfaceLibs ${_linkInterfaceLibs})
+ # resolve $NOT:(0|1)
+ string(REGEX REPLACE \\$NOT:0 1
+ _linkInterfaceLibs ${_linkInterfaceLibs})
+ string(REGEX REPLACE \\$NOT:1 0
+ _linkInterfaceLibs ${_linkInterfaceLibs})
+ # resolve $(0|1):...
+ # empty items will be ignored by `foreach` later
+ string(REGEX REPLACE \\$0:[^]*
+ _linkInterfaceLibs ${_linkInterfaceLibs})
+ string(REGEX REPLACE \\$1:([^]*) \\1
+ _linkInterfaceLibs ${_linkInterfaceLibs})
+else()
+ get_target_property(_linkInterfaceLibs ${_CURRENT_LIB}
IMPORTED_LINK_INTERFACE_LIBRARIES_${_importedConfigToUse} )
+endif()
list(APPEND _CCSR_NEW_REQ_LIBS ${_importedLocation})
#message(STATUS Appending lib ${_CURRENT_LIB} as
${_importedLocation})
--
1.9.4.msysgit.2
--
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 0015654]: Need generator expression CONFIG that works for both multi-config and single config generators
The following issue has been SUBMITTED.
==
http://www.cmake.org/Bug/view.php?id=15654
==
Reported By:James Bigler
Assigned To:
==
Project:CMake
Issue ID: 15654
Category: CMake
Reproducibility:N/A
Severity: feature
Priority: normal
Status: new
==
Date Submitted: 2015-07-15 13:35 EDT
Last Modified: 2015-07-15 13:35 EDT
==
Summary:Need generator expression CONFIG that works for both
multi-config and single config generators
Description:
The value of $CONFIG works just fine for generators like Visual Studio (e.g.
Debug, RelWithDebInfo), but for generators like Makefiles it maps to
CMAKE_BUILD_TYPE, which is less useful for doing stuff like this:
file(GENERATE ${CMAKE_RUNTIME_OUTPUT_DIRECTORY}/$CONFIG/myfile)
This will do the right thing for VS, but not for Makefile. It would be helpful
to have such a value that could make this work.
==
Issue History
Date ModifiedUsername FieldChange
==
2015-07-15 13:35 James Bigler 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] Adding an option for relative compiler invocations
Michael Enßlin michael@... writes: Over the last several decades, at least on the POSIX platform, it has become common practice to invoke compilers with relative file paths, and compilers have adopted to act accordingly. While the true culprit is the C standard's lax definition of __FILE__, I'm blaming cmake's unusual, absolute-path invocation behavior. FYI: http://thread.gmane.org/gmane.comp.lang.c++.isocpp.general/6088 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] Generator expressions for archive|library|runtime output directory
Robert Goulet wrote: Greetings! Patch in attachment for all OUTPUT_DIRECTORY variants to support generator expressions. Thanks! There are two signatures for cmCompiledGeneratorExpression::Evaluate. Did you use the correct one? Does this support all generator expressions? Including TARGET_PROPERTY? I didn't check/test this. These are just review comments. 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] Add command line options for deprecation message control
Looking at the cmMessageCommand::InitialPass and cmake::PrintMessagePreamble code, if we want to mirror the deprecation message behaviour, I'm tempted to suggest we also modify the message mode AUTHOR_WARNING to be AUTHOR instead. It would make the mode clearer on it's new behaviour and allow the code to be more consistent with regards to dev and deprecated. I imagine this might be a big user affecting change though, so it might be better to not do that and just make AUTHOR_WARNING cause fatal error messages depending on the state of the associated cmake variables. What are your thoughts on this? P.S. Sorry my previous email broke the message threading, I'm replying in a different way this time but please let me know if I'm still breaking the message threading. Cheers, Michael -- 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] Generator expressions for archive|library|runtime output directory
I didn't know about the two signature of cmCompiledGeneratorExpression::Evaluate, what's the difference? Could it create an issue? As for the TARGET_PROPERTY generator expression, are you suggesting this could potentially be an issue? I haven't tried it. -Original Message- From: cmake-developers [mailto:cmake-developers-boun...@cmake.org] On Behalf Of Stephen Kelly Sent: Wednesday, July 15, 2015 5:17 PM To: cmake-developers@cmake.org Subject: Re: [cmake-developers] Generator expressions for archive|library|runtime output directory Robert Goulet wrote: Greetings! Patch in attachment for all OUTPUT_DIRECTORY variants to support generator expressions. Thanks! There are two signatures for cmCompiledGeneratorExpression::Evaluate. Did you use the correct one? Does this support all generator expressions? Including TARGET_PROPERTY? I didn't check/test this. These are just review comments. 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 -- 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 0015652]: get_target_property() called with non-existent target boost_chrono-mt-shared
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=15652 == Reported By:Mathieu Malaterre Assigned To: == Project:CMake Issue ID: 15652 Category: CMake Reproducibility:have not tried Severity: minor Priority: normal Status: new == Date Submitted: 2015-07-15 08:28 EDT Last Modified: 2015-07-15 08:28 EDT == Summary:get_target_property() called with non-existent target boost_chrono-mt-shared Description: I cannot use FindBoost.cmake on CentOS6 (boost 1.41), it fails with: CMake Error at /usr/lib64/boost/BoostConfig.cmake:64 (get_target_property): get_target_property() called with non-existent target boost_chrono-mt-shared. Call Stack (most recent call first): /opt/tools/cmake-3.0.1/share/cmake-3.0/Modules/FindBoost.cmake:206 (find_package) CMakeLists.txt:33 (find_package) CMake Error at /usr/lib64/boost/BoostConfig.cmake:72 (get_target_property): get_target_property() called with non-existent target boost_chrono-mt-shared-debug. Call Stack (most recent call first): /opt/tools/cmake-3.0.1/share/cmake-3.0/Modules/FindBoost.cmake:206 (find_package) CMakeLists.txt:33 (find_package) Boost 1.41 found. == Issue History Date ModifiedUsername FieldChange == 2015-07-15 08:28 Mathieu MalaterreNew 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] [PATCH] Extended Nsight Tegra support for CMake
We use it for our game engine Android development, and I must say this is definitively super awesome. Looking forward for these improvements! Thanks a lot for all this work. -Original Message- From: cmake-developers [mailto:cmake-developers-boun...@cmake.org] On Behalf Of Mikhail Filimonov Sent: Wednesday, July 15, 2015 10:14 AM To: Brad King Cc: cmake-developers@cmake.org Subject: Re: [cmake-developers] [PATCH] Extended Nsight Tegra support for CMake Thanks, Brad. As usual, we're open for community feedback on Nsight Tegra project generator. -Mikhail -Original Message- From: Brad King [mailto:brad.k...@kitware.com] Sent: 15 июля 2015 г. 16:10 To: Mikhail Filimonov Cc: cmake-developers@cmake.org; Dmitry Polyanitsa Subject: Re: [cmake-developers] [PATCH] Extended Nsight Tegra support for CMake On 07/13/2015 12:44 PM, Mikhail Filimonov wrote: I've improved the patch according to the Brad's and Dmitry's comments - namely: 1. Improved the documentation for a few target properties. 2. Removed the explicit toolchain file for Nsight Tegra generator test. 3. Improved the generator heuristics for NsightTegraProjectRevisionNumber attribute. Thanks. I've applied the patch with minor tweaks: VS: Add more Nsight Tegra generator Android property settings http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=8c0afaf4 -Brad --- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. --- -- 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 -- 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] Adding Swift support to CMake
On 07/15/2015 06:16 AM, Eric Wing wrote: I just tried out the July 15th nightly build and it looks like it is working (Xcode generator). I got a little fancy and did an intermixed C/Swift test. I have a simple SDL (C) based program with Swift bindings and I'm able to build/run it and step the Xcode debugger through the Swift parts. Great, thanks for testing. So is the next step the Makefile generator? The Makefile and Ninja generators should be done together. I recently refactored things to help them share more infrastructure. The hard part is figuring out what command lines actually need to be invoked. There is no documentation from Apple for this AFAIK so someone will have to figure it out based on what Xcode does. I have no time to work on any of this myself. My goal with getting it working in Xcode was just to do the minimum needed to get the basic language module infrastructure in place within CMake. Others will have to take over from there. -Brad -- 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] [PATCH] Extended Nsight Tegra support for CMake
Thanks, Brad. As usual, we're open for community feedback on Nsight Tegra project generator. -Mikhail -Original Message- From: Brad King [mailto:brad.k...@kitware.com] Sent: 15 июля 2015 г. 16:10 To: Mikhail Filimonov Cc: cmake-developers@cmake.org; Dmitry Polyanitsa Subject: Re: [cmake-developers] [PATCH] Extended Nsight Tegra support for CMake On 07/13/2015 12:44 PM, Mikhail Filimonov wrote: I've improved the patch according to the Brad's and Dmitry's comments - namely: 1. Improved the documentation for a few target properties. 2. Removed the explicit toolchain file for Nsight Tegra generator test. 3. Improved the generator heuristics for NsightTegraProjectRevisionNumber attribute. Thanks. I've applied the patch with minor tweaks: VS: Add more Nsight Tegra generator Android property settings http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=8c0afaf4 -Brad --- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. --- -- 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] [PATCH] CMakeExpandImportedTargets: use INTERFACE_LINK_LIBRARIES if non-empty
The CMakeExpandedImportedTargets module used only the deprecated
IMPORTED_LINK_INTERFACE_LIBRARIES property to resolve transitive
dependencies.
Since the current `install(EXPORT ...)` command generates target files that
populate INTERFACE_LINK_LIBRARIES instead, the expand module was not
working correctly with the imported libraries generated by `install(EXPORT
...)`.
I considered this a bugfix so I based the commit onto the release branch.
Please review and apply if it's ok.
Tamas
From f2df88ec4180595a3fcc4c6be9b2d38e46162cc3 Mon Sep 17 00:00:00 2001
From: Tamas Kenez tamas.ke...@gmail.com
Date: Wed, 15 Jul 2015 17:47:50 +0200
Subject: [PATCH] CMakeExpandImportedTargets: use INTERFACE_LINK_LIBRARIES if
non-empty
The deprecated IMPORTED_LINK_INTERFACE_LIBRARIES should be
overridden by INTERFACE_LINK_LIBRARIES if it's non-empty.
Unlike IMPORTED_LINK_INTERFACE_LIBRARIES, INTERFACE_LINK_LIBRARIES
usually contains config-related generator expressions which must
be resolved according to the selected configuration.
---
Modules/CMakeExpandImportedTargets.cmake | 22 +-
1 file changed, 21 insertions(+), 1 deletion(-)
diff --git a/Modules/CMakeExpandImportedTargets.cmake
b/Modules/CMakeExpandImportedTargets.cmake
index 8ac3364..b110e51 100644
--- a/Modules/CMakeExpandImportedTargets.cmake
+++ b/Modules/CMakeExpandImportedTargets.cmake
@@ -102,7 +102,27 @@ function(CMAKE_EXPAND_IMPORTED_TARGETS _RESULT )
list(GET _importedConfigs ${_configIndexToUse}
_importedConfigToUse)
get_target_property(_importedLocation ${_CURRENT_LIB}
IMPORTED_LOCATION_${_importedConfigToUse})
-get_target_property(_linkInterfaceLibs ${_CURRENT_LIB}
IMPORTED_LINK_INTERFACE_LIBRARIES_${_importedConfigToUse} )
+get_target_property(_linkInterfaceLibs ${_CURRENT_LIB}
INTERFACE_LINK_LIBRARIES)
+if(_linkInterfaceLibs)
+ # resolve $CONFIG:... generator expressions
+ string(REGEX REPLACE \\$CONFIG:${_importedConfigToUse}
1
+ _linkInterfaceLibs ${_linkInterfaceLibs})
+ string(REGEX REPLACE \\$CONFIG:[^]* 0
+ _linkInterfaceLibs ${_linkInterfaceLibs})
+ # resolve $NOT:(0|1)
+ string(REGEX REPLACE \\$NOT:0 1
+ _linkInterfaceLibs ${_linkInterfaceLibs})
+ string(REGEX REPLACE \\$NOT:1 0
+ _linkInterfaceLibs ${_linkInterfaceLibs})
+ # resolve $(0|1):...
+ # empty items will be ignored by `foreach` later
+ string(REGEX REPLACE \\$0:[^]*
+ _linkInterfaceLibs ${_linkInterfaceLibs})
+ string(REGEX REPLACE \\$1:([^]*) \\1
+ _linkInterfaceLibs ${_linkInterfaceLibs})
+else()
+ get_target_property(_linkInterfaceLibs ${_CURRENT_LIB}
IMPORTED_LINK_INTERFACE_LIBRARIES_${_importedConfigToUse} )
+endif()
list(APPEND _CCSR_NEW_REQ_LIBS ${_importedLocation})
#message(STATUS Appending lib ${_CURRENT_LIB} as
${_importedLocation})
--
1.9.4.msysgit.2
--
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] OSX - Application bundle and private frameworks?
On 07/13/2015 06:43 PM, Raffi Enficiaud wrote:
- and I specify the location of those frameworks within the application
bundle:
set_source_files_properties(${fcCamFramework} PROPERTIES
MACOSX_PACKAGE_LOCATION Frameworks)
set_source_files_properties(${sbigudFramework} PROPERTIES
MACOSX_PACKAGE_LOCATION Frameworks)
The problem is the following:
- Everything works fine with XCode, I have the full content of the
frameworks at the specified location
- When I use the Makefile generator, I have only one file per framework
instead of the directory and the framework content:
The MACOSX_PACKAGE_LOCATION source file property was created
for marking individual source files. The possibility of marking
a (framework) directory with the property was never considered
AFAIK. For Xcode it may work by accident. I would not be opposed
to a change to make something like this work for directories too,
but someone would have to investigate it.
Meanwhile take a look at the BundleUtilities module:
http://www.cmake.org/cmake/help/v3.3/module/BundleUtilities.html
and its fixup_bundle() helper. They are meant for preparing
complete bundles for packaging and distribution.
-Brad
--
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] Suggestion to add EUROS RTOS platform description
On 07/14/2015 11:52 AM, Stanimir Kabaivanov wrote: I would like to contribute with EUROS RTOS platform description file that would allow us to build EUROS RTOS projects with CMake. Thanks. Applied with minor tweaks: Add EUROS RTOS platform description file http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=606b29d4 The multi-inclusion guard is not needed here. The guard in eCos.cmake is specific to that module's use of add_definitions (which platform modules are normally not supposed to do). -Brad -- 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] [PATCH] Extended Nsight Tegra support for CMake
On 07/13/2015 12:44 PM, Mikhail Filimonov wrote: I've improved the patch according to the Brad's and Dmitry's comments - namely: 1. Improved the documentation for a few target properties. 2. Removed the explicit toolchain file for Nsight Tegra generator test. 3. Improved the generator heuristics for NsightTegraProjectRevisionNumber attribute. Thanks. I've applied the patch with minor tweaks: VS: Add more Nsight Tegra generator Android property settings http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=8c0afaf4 -Brad -- 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] Listing source-tree files encountered (was: Wrapping functions in CMake)
On 07/09/2015 01:35 PM, Clifford Yapp wrote: 1. First, we need to maintain a list of all files in the source repository that are known to the build system. To do this we maintain a global list of files, define a custom CMAKEFILES command to allow us to manually specify miscellaneous files as known, and override all of the primary target creating commands to add their files to the list (for example, add_executable is passed a list of source files, and all of those files are automatically added to the known files list by the function override of add_executable.) This list is used for both our make-clean-in-src-dir feature and our distcheck build target (which does a number of verification steps using the version control system, the build system and the files-on-filesystem information to make sure the build logic is current.) These days it is the job of version control tools to know what files are part of the source and what files are not. Commands like git clean are then responsible for cleaning out a source tree, not the build system. CMake is mainly designed for out-of-source builds where nothing in the source tree is touched at all. This makes distclean unnecessary. We support in-source builds for end-user convenience when installing a project from a source tarball, but in general development should always be done with out-of-source builds to keep the source pristine. 1. Have CMake internally maintain a list (or maybe per-command lists for more flexibility) of all files with paths relative to the root source directory that have been observed by add_executable, add_library, add_custom_target, add_subdirectory, and configure_file that can be accessed via CMake variables Many of the source file locations are not actually determined until generate time, so a configuration-time list is not possible to implement reliably in general. Maintaining the list would force source file locations to be finalized too early. -Brad -- 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] [Patch] Added property to disable the Built target progress messages in Makefile targets
On 07/10/2015 03:18 PM, Michael Enßlin wrote: The patch adds a global property, TARGET_MESSAGES, which behaves analogous to RULE_MESSAGES in that it can be explicitly set to OFF to suppress some build output. Thanks! I've applied it with minor tweaks: Makefile: Optionally disable target completion messages in build output http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=1d398478 I also added test cases: Tests: Add test for TARGET_MESSAGES global property http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f0cad193 -Brad -- 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] Capturing messages to log files (was: Wrapping functions in CMake)
On 07/09/2015 01:53 PM, Clifford Yapp wrote: Actually, thinking about that, what's really needed is not an in-memory log but a way to specify log files, since an unexpected crash or exit is not a situation under which such in-memory logs could be reliably written to disk. So it would instead need to be CMAKE_STATUS_MESSAGE_LOG, CMAKE_ERROR_MESSAGES_LOG, etc. which would hold paths to which messages would be copied before being written to stdout/stderr. These could be defined as GLOBAL properties since there can only be one. Internally we already have callback infrastructure to dispatch where these messages go. Hooks could be added to check these properties too. Or, the property setting logic could have special handling for these properties to install the needed callbacks internally. This approach would avoid opening/closing the log files over and over. We could just keep them open all the time and flush after each write. -Brad -- 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] Listing all targets (was: Wrapping functions in CMake)
On 07/10/2015 03:42 PM, Clifford Yapp wrote: On Thu, Jul 9, 2015 at 1:35 PM, Clifford Yapp cliffy...@gmail.com wrote: 2. Provide similar lists of all defined targets for the various types (e.g. CMAKE_EXECUTABLE_TARGETS, CMAKE_LIBRARY_TARGETS, CMAKE_CUSTOM_TARGETS). Looking into the CMake sources, it seems like this information is stored already in the global target map - what would be the correct way to expose that information in variables in CMake script space? We shouldn't need separate lists for each because one can check the TYPE target property given the target name. The list of globally-scoped (non-imported) targets could be made available through a (read-only) global property whose implementation computes the list on the fly. -Brad -- 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] C# support?
On 07/02/2015 09:53 AM, Stuermer, Michael SP/HZA-ZSEP wrote: I got the first sort of working version running. Would be great if some people could have a look at it if it's going into a good direction. Thanks again for working on this. Sorry for the delay in response. I was working on the basic Apple Swift support and thought it could be a useful example for CSharp work. Patch 0001: - adds the necessary Module/* files for enabling C# as a language Some of the CMakeCSharpInformation module content like: +set(CMAKE_CSharp_FLAGS_INIT /define:TRACE /langversion:3 /nowin32manifest) +set(CMAKE_CSharp_FLAGS_DEBUG_INIT /debug:full /optimize- /warn:3 /errorreport:prompt /define:DEBUG) +set(CMAKE_CSharp_FLAGS_RELEASE_INIT /debug:none /optimize /warn:1 /errorreport:queue) +set(CMAKE_CSharp_FLAGS_RELWITHDEBINFO_INIT /debug:full /optimize-) +set(CMAKE_CSharp_FLAGS_MINSIZEREL_INIT /debug:none /optimize) belongs in a file such as Modules/Platform/Windows-MSVC-CSharp.cmake file. The CMakeCSharpInformation file should have only information specific to the C# language and not any particular toolchain and then load other modules that provide information specific to the platform and toolchain vendor (compiler id). See the recently added CMakeSwiftInformation module for an example. Patch 0002: - some minor changes to mostly visual studio related classes to enable .csproj support o .csproj GUID is added o a method to check if the target is C# is added Looks good at a glance. Patch 0003: - the actual implementation of the .csproj generation - all generation takes place inside VisualStudio10TargetGenerator class That looks like the right direction. How did you generate the flag table? The other flag tables we have for VS = 10 generators are generated by Source/cmparseMSBuildXML.py. See commit VS14: Generate flag tables from MSBuild v140 tool files http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d96b3f68 for an example. Typically we add a new flag table generated by the script in one commit and then add follow-up commits to apply manual tweaks. That way we know exactly how to reproduce the table. Thanks, -Brad -- 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] topic 'ctest-change-id'
Hi, The new element `ChangeId` is added to Build.xml and Test.xml. Did you consider adding it as an attribute in `cmCTest::StartXML` instead? That would make this (very useful) information available in all xml files. cheers, Daniel -- 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] topic 'ctest-change-id'
On 07/15/2015 10:57 AM, Daniel Pfeifer wrote: The new element `ChangeId` is added to Build.xml and Test.xml. Did you consider adding it as an attribute in `cmCTest::StartXML` instead? That would make this (very useful) information available in all xml files. I think that would make sense since all submitted .xml files are associated with the change identified by the ChangeId. Zack? Thanks, -Brad -- 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] topic 'ctest-change-id'
On Wed, Jul 15, 2015 at 11:07 AM, Brad King brad.k...@kitware.com wrote: On 07/15/2015 10:57 AM, Daniel Pfeifer wrote: The new element `ChangeId` is added to Build.xml and Test.xml. Did you consider adding it as an attribute in `cmCTest::StartXML` instead? That would make this (very useful) information available in all xml files. I think that would make sense since all submitted .xml files are associated with the change identified by the ChangeId. Zack? I did consider that. The reason I went with the current approach is that StartXML() only defines attributes on the Site tag, which doesn't logically seem like the right location for this information. Change ID should be associated with the build/test/update/etc step being performed. Instead, I followed the example set by StartDateTime, which is independently set by each of the CTest handlers. That being said, I don't have very strong feelings about this, so if you're all okay with Change ID being a Site attribute I could move it to StartXML(). -- 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
