Re: [cmake-developers] Listing all targets (was: Wrapping functions in CMake)
This would best be added as a TARGETS variant of the existing http://www.cmake.org/cmake/help/v3.3/command/get_cmake_property.html command. (In my opinion...) David C. On Thu, Jul 16, 2015 at 11:42 AM, Clifford Yapp cliffy...@gmail.com wrote: On Wed, Jul 15, 2015 at 9:10 AM, Brad King brad.k...@kitware.com wrote: 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. Ah, good point. 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. Sounds workable - are there any pre-existing properties like that that can serve as a guide for implementation? 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 -- 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 0015656]: pls. add CPACK_RPM_PACKAGE_CONFLICTS
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=15656 == Reported By:Frank-Christian Otto Assigned To: == Project:CMake Issue ID: 15656 Category: CPack Reproducibility:N/A Severity: minor Priority: normal Status: new == Date Submitted: 2015-07-16 05:38 EDT Last Modified: 2015-07-16 05:38 EDT == Summary:pls. add CPACK_RPM_PACKAGE_CONFLICTS Description: RPM packaging via cpack allows to set positive dependencies using CPACK_RPM_PACKAGE_REQUIRES RPM also allows negative dependencies (packages that must not be installed). I patched Modules/CPackRPM.cmake to support this. Pls. consider adding this to the code base. patch added as attachment == Issue History Date ModifiedUsername FieldChange == 2015-07-16 05:38 Frank-Christian OttoNew Issue 2015-07-16 05:38 Frank-Christian OttoFile Added: Modules_CPackRPM.cmake_3.2_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] [PATCH] CMakeExpandImportedTargets: use INTERFACE_LINK_LIBRARIES if non-empty
I submitted a patch to update `CMakeExpandImportedTargets` with
`INTERFACE_LINK_LIBRARIES`.
Shortly after I read the discussion at http://www.cmake
.org/Bug/view.php?id=15299 which suggested `CMakeExpandImportedTargets` is
deprecated and one should use `BundleUtilities` instead.
Well, it seems that `BundleUtilities` can't expand a single static imported
library target to the list of all dependent libraries (that's what I need)
so I think `CMakeExpandImportedTargets` is still benefitial and could be
benefitial to others, too.
My patch enables `CMakeExpandImportedTargets` to use the
`INTERFACE_LINK_LIBRARIES`
property and also resolves the $CONFIG, $NOT and $0|1: generator
expressions. I found no elegant way to resolve all generator expressions
(`file(GENERATE ...)` can't be used since it does not output the resolved
content instantly).
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
Re: [cmake-developers] Listing all targets (was: Wrapping functions in CMake)
On Wed, Jul 15, 2015 at 9:10 AM, Brad King brad.k...@kitware.com wrote: 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. Ah, good point. 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. Sounds workable - are there any pre-existing properties like that that can serve as a guide for implementation? 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
Re: [cmake-developers] Capturing messages to log files (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: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. Makes sense. 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. Sounds good! (Always in favor of less filesystem hits, especially on Windows...) In hopes of writing an acceptable patch, is there an approach that would be preferred? Cheers, 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
