Re: [cmake-developers] Add command line options for deprecation message control
On 07/15/2015 05:08 PM, Michael Scott wrote: 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? I think the name AUTHOR_WARNING is fine even after these changes because the new options explicitly request to make these warnings into errors. C++ compiler #pragma warn-like options are spelled warn but can still be errors with the right options. 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. It still breaks the threading. Your first few responses (e.g. on 2015-06-24) were threaded correctly. -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] Generator expressions for archive|library|runtime output directory
On 07/15/2015 05:27 PM, Robert Goulet wrote:
I didn't know about the two signature of
cmCompiledGeneratorExpression::Evaluate, what's the difference?
As for the TARGET_PROPERTY generator expression, are you suggesting
this could potentially be an issue? I haven't tried it.
If cmCompiledGeneratorExpression::Evaluate is given the current
target (this) as the headTarget then one can use the
TARGET_PROPERTY generator expression to refer to other properties
on the target whose name is being determined. This would be nice
to have but could also be enabled by future changes so I won't
insist on it now.
Your original patch did not evaluate the generator expressions
in quite the right place. On Wednesday I had updated the patch
and applied for testing in 'next':
Add genex for {ARCHIVE,LIBRARY,RUNTIME}_OUTPUT_DIRECTORY[_CONFIG]
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f6f05443
Although testing was clean, I reverted the change from 'next'
this morning after Steve's review led me to realize that the
change causes a crash in a self-reference case like:
set_property(TARGET myexe PROPERTY RUNTIME_OUTPUT_DIRECTORY
$TARGET_FILE_DIR:myexe)
This is also a problem for the recent OUTPUT_NAME changes:
set_property(TARGET myexe PROPERTY OUTPUT_NAME $TARGET_FILE_NAME:myexe)
In each case the implementation fails to diagnose the ill-defined
self-reference case. Fixing these cases may require some kind
of check in cmTarget methods to see if they end up being called
recursively.
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] install(EXCLUDE_FROM_ALL) new feature - request for comment
There is currently no way to exclude a component install() from a full installation. Current workarounds using OPTIONAL do not work reliably because they depend on previous builds and on the order execution of the build and install commands for the components and the default target Steps to Reproduce: make make tests make install DESTDIR=/testpkgs make install-tests This results in test components in the default installation as well as the testpkg Judging by questions on the mail list, users typically try to overcome this problem by adding the unsupported EXCLUDE_FROM_ALL keyword to the install command http://www.cmake.org/Bug/view.php?id=14921 Interesting proposal. I think a change along these lines could also improve a case mentioned in the install() command documentation: http://www.cmake.org/cmake/help/v3.0/command/install.html Installing a target with the EXCLUDE_FROM_ALL target property set to TRUE has undefined behavior. That refers to the use case when a target build is EXCLUDE_FROM_ALL and so is not created by make and may then be missing when make install is issued. This looks intended to support the same use case by making the install rule excluded from the default installation too. Perhaps install(TARGETS) should activate ExcludeFromAll when the corresponding property is set on the target. Rebased patch on 3.2.2. Still no automatic setting of install(EXCLUDE_FROM_ALL) based on the setting of add_executable(EXCLUDE_FROM_ALL) though Thanks for working on this. I think it will be better discussed on the cmake-developers mailing list: http://www.cmake.org/mailman/listinfo/cmake-developers That allows for design discussion with a broader audience than the issue -- This company is part of the G4S group of companies. This communication contains information which may be confidential, personal and/or privileged. It is for the exclusive use of the intended recipient(s). If you are not the intended recipient(s), please note that any distribution, forwarding, copying or use of this communication or the information in it is strictly prohibited. Any personal views expressed in this e-mail are those of the individual sender and the Company does not endorse or accept responsibility for them. Prior to taking any action based upon this e-mail message, you should seek appropriate confirmation of its authenticity. This message has been checked for viruses on behalf of the Company. -- 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 Thu, Jul 16, 2015 at 13:27:12 -0400, David Cole via cmake-developers wrote: 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...) The get_property command would also need to handle it. I don't know if it hooks into the more specific commands' implementations though. Doesn't seem like it from a cursory reading though. --Ben -- 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
Ok I'd like to fix the crash, what is the clean way to deal with this kind of
situation? I'm guessing this might be a problem that was solved elsewhere for
other cases before?
-Original Message-
From: Brad King [mailto:brad.k...@kitware.com]
Sent: Friday, July 17, 2015 10:44 AM
To: Robert Goulet
Cc: Stephen Kelly; cmake-developers@cmake.org
Subject: Re: [cmake-developers] Generator expressions for
archive|library|runtime output directory
On 07/15/2015 05:27 PM, Robert Goulet wrote:
I didn't know about the two signature of
cmCompiledGeneratorExpression::Evaluate, what's the difference?
As for the TARGET_PROPERTY generator expression, are you suggesting
this could potentially be an issue? I haven't tried it.
If cmCompiledGeneratorExpression::Evaluate is given the current target (this)
as the headTarget then one can use the TARGET_PROPERTY generator expression to
refer to other properties on the target whose name is being determined. This
would be nice to have but could also be enabled by future changes so I won't
insist on it now.
Your original patch did not evaluate the generator expressions in quite the
right place. On Wednesday I had updated the patch and applied for testing in
'next':
Add genex for {ARCHIVE,LIBRARY,RUNTIME}_OUTPUT_DIRECTORY[_CONFIG]
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f6f05443
Although testing was clean, I reverted the change from 'next'
this morning after Steve's review led me to realize that the change causes a
crash in a self-reference case like:
set_property(TARGET myexe PROPERTY RUNTIME_OUTPUT_DIRECTORY
$TARGET_FILE_DIR:myexe)
This is also a problem for the recent OUTPUT_NAME changes:
set_property(TARGET myexe PROPERTY OUTPUT_NAME $TARGET_FILE_NAME:myexe)
In each case the implementation fails to diagnose the ill-defined
self-reference case. Fixing these cases may require some kind of check in
cmTarget methods to see if they end up being called recursively.
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] [PATCH] CMakeExpandImportedTargets: use INTERFACE_LINK_LIBRARIES if non-empty
On 07/16/2015 11:29 AM, Tamás Kenéz wrote: 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. The BundleUtilities suggestion in the issue tracker page you linked was specific to the CPack use case discussed there. My patch enables `CMakeExpandImportedTargets` to use the `INTERFACE_LINK_LIBRARIES` property and also resolves the $CONFIG, $NOT and $0|1: generator expressions. This module should not be further maintained and should instead be deprecated: * Its original use case was to expand imported targets for calling try_compile and try_run. Both now support imported targets natively in their LINK_LIBRARIES options so it is no longer needed (or used by CMake's own modules) for this purpose. * It is not possible to implement with generator expressions in general (see below). 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). Generator expressions by definition cannot be evaluated until generate time because their evaluation can access information that is not available until then. Even for imported targets with a given CONFIGURATION value we may not have all the information needed to expand INTERFACE_LINK_LIBRARIES. For example, that property may contain expressions like $TARGET_PROPERTY:prop that refer to the target for which the link line is currently generating. What is your actual use case for expanding this info during the configuration process? -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] Generator expressions for archive|library|runtime output directory
On 07/17/2015 10:55 AM, Robert Goulet wrote: Ok I'd like to fix the crash, what is the clean way to deal with this kind of situation? I'm guessing this might be a problem that was solved elsewhere for other cases before? I don't recall other cases where this specific problem has come up. There is code to deal with generator expression reference cycles e.g. for $TARGET_PROPERTY:... expressions but that is not quite the same thing. For the OUTPUT_DIRECTORY case the GetOutputInfo method: http://www.cmake.org/gitweb?p=cmake.git;a=blob;f=Source/cmTarget.cxx;hb=v3.3.0-rc4#l2612 memoizes the ComputeOutputDir result in a map. Currently it does not update the map until after computing the value. You could try teaching it to insert a placeholder (empty?) value in the map first. Then in the check for an existing map entry, if it is found to contain the placeholder then you know recursion is occurring and you can diagnose it with an error message and return early. The GetOutputName method could be refactored to use a map and then work the same way. 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] [PATCH] CMakeExpandImportedTargets: use INTERFACE_LINK_LIBRARIES if non-empty
What is your actual use case for expanding this info during the configuration process? We feed our static lib and the list of its dependencies to the `libtool` to create an amalgamated, standalone static library. This is an iOS-specific issue: we need this because iOS doesn't support shared libraries and we want to provide our users a single static lib instead of 20-30. Anyway, I understand if `CMakeExpandImportedTargets' doesn't fit the current concepts. We will then use a local modified copy of it or try to solve the issue by `install(CODE ..)` to postpone the amalgamation to install time where the generator expressions can be resolved. Thanks, Tamas (sorry for not replying-to-all in previous email) On Fri, Jul 17, 2015 at 5:41 PM, Brad King brad.k...@kitware.com wrote: On 07/16/2015 11:29 AM, Tamás Kenéz wrote: 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. The BundleUtilities suggestion in the issue tracker page you linked was specific to the CPack use case discussed there. My patch enables `CMakeExpandImportedTargets` to use the `INTERFACE_LINK_LIBRARIES` property and also resolves the $CONFIG, $NOT and $0|1: generator expressions. This module should not be further maintained and should instead be deprecated: * Its original use case was to expand imported targets for calling try_compile and try_run. Both now support imported targets natively in their LINK_LIBRARIES options so it is no longer needed (or used by CMake's own modules) for this purpose. * It is not possible to implement with generator expressions in general (see below). 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). Generator expressions by definition cannot be evaluated until generate time because their evaluation can access information that is not available until then. Even for imported targets with a given CONFIGURATION value we may not have all the information needed to expand INTERFACE_LINK_LIBRARIES. For example, that property may contain expressions like $TARGET_PROPERTY:prop that refer to the target for which the link line is currently generating. What is your actual use case for expanding this info during the configuration process? -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
On 07/15/2015 10:38 PM, Clifford Yapp wrote: 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. Once the list of all targets is available in a global property as discussed in another branch of this thread, then you could loop over that and check the SOURCES target property to get the list of original path specifiers. That would handle almost everything. What would be left for your use case? -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)
Are you saying there should be a named GLOBAL property with this information in it...? It seems like more of a fit to get_cmake_property. On Fri, Jul 17, 2015 at 10:14 AM, Ben Boeckel ben.boec...@kitware.com wrote: On Thu, Jul 16, 2015 at 13:27:12 -0400, David Cole via cmake-developers wrote: 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...) The get_property command would also need to handle it. I don't know if it hooks into the more specific commands' implementations though. Doesn't seem like it from a cursory reading though. --Ben -- 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 Fri, Jul 17, 2015 at 14:16:34 -0400, David Cole wrote: get_cmake_property is more like strictly well-pre-defined, read only (ish), built-into CMake properties. Note there is no set_cmake_property... What docs are you looking at that you think have a bug...? Help/command/get_cmake_property: get_cmake_property -- Get a property of the CMake instance. :: get_cmake_property(VAR property) Get a property from the CMake instance. The value of the property is stored in the variable VAR. If the property is not found, VAR will be set to NOTFOUND. Some supported properties include: VARIABLES, CACHE_VARIABLES, COMMANDS, MACROS, and COMPONENTS. See also the more general get_property() command. `get_property` has no way (that I see) to ask for the same properties. The whole command docs could use a revamp too (while TARGETS is being implemented to avoid conflicts?). --Ben -- 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)
I think the see also is relevant because it points to another way to get to a whole different set of properties. Perhaps what they're looking for when they stumble upon get_cmake_property is actually target properties, which are only accessible via get_property. While it's relevant, and I think it should remain, I do think it could use some clarification. I'll take a stab at this, and clarify the docs, too, unless somebody else chimes in and tells me wait! I'm doing it already :-) Cheers, David C. On Fri, Jul 17, 2015 at 2:55 PM, Ben Boeckel ben.boec...@kitware.com wrote: On Fri, Jul 17, 2015 at 14:16:34 -0400, David Cole wrote: get_cmake_property is more like strictly well-pre-defined, read only (ish), built-into CMake properties. Note there is no set_cmake_property... What docs are you looking at that you think have a bug...? Help/command/get_cmake_property: get_cmake_property -- Get a property of the CMake instance. :: get_cmake_property(VAR property) Get a property from the CMake instance. The value of the property is stored in the variable VAR. If the property is not found, VAR will be set to NOTFOUND. Some supported properties include: VARIABLES, CACHE_VARIABLES, COMMANDS, MACROS, and COMPONENTS. See also the more general get_property() command. `get_property` has no way (that I see) to ask for the same properties. The whole command docs could use a revamp too (while TARGETS is being implemented to avoid conflicts?). --Ben -- 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)
get_cmake_property is more like strictly well-pre-defined, read only (ish), built-into CMake properties. Note there is no set_cmake_property... What docs are you looking at that you think have a bug...? To implement TARGETS for get_cmake_property, I would look to see what logic is used by if(TARGET and use the same list it uses as the value returned here. Should I work on a patch/branch, or is somebody here already working on it? D On Fri, Jul 17, 2015 at 1:54 PM, Ben Boeckel ben.boec...@kitware.com wrote: On Fri, Jul 17, 2015 at 12:18:18 -0400, David Cole wrote: Are you saying there should be a named GLOBAL property with this information in it...? It seems like more of a fit to get_cmake_property. Indeed. It seems there is no overlap between `get_property` and `get_cmake_property`. Which means the docs have a bug. --Ben -- 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'm going to be away for a few weeks, is it ok if the master branch stays in that state for a while? -Original Message- From: Brad King [mailto:brad.k...@kitware.com] Sent: Friday, July 17, 2015 11:47 AM To: Robert Goulet Cc: Stephen Kelly; cmake-developers@cmake.org Subject: Re: [cmake-developers] Generator expressions for archive|library|runtime output directory On 07/17/2015 10:55 AM, Robert Goulet wrote: Ok I'd like to fix the crash, what is the clean way to deal with this kind of situation? I'm guessing this might be a problem that was solved elsewhere for other cases before? I don't recall other cases where this specific problem has come up. There is code to deal with generator expression reference cycles e.g. for $TARGET_PROPERTY:... expressions but that is not quite the same thing. For the OUTPUT_DIRECTORY case the GetOutputInfo method: http://www.cmake.org/gitweb?p=cmake.git;a=blob;f=Source/cmTarget.cxx;hb=v3.3.0-rc4#l2612 memoizes the ComputeOutputDir result in a map. Currently it does not update the map until after computing the value. You could try teaching it to insert a placeholder (empty?) value in the map first. Then in the check for an existing map entry, if it is found to contain the placeholder then you know recursion is occurring and you can diagnose it with an error message and return early. The GetOutputName method could be refactored to use a map and then work the same way. 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] Listing all targets (was: Wrapping functions in CMake)
On Fri, Jul 17, 2015 at 12:18:18 -0400, David Cole wrote: Are you saying there should be a named GLOBAL property with this information in it...? It seems like more of a fit to get_cmake_property. Indeed. It seems there is no overlap between `get_property` and `get_cmake_property`. Which means the docs have a bug. --Ben -- 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 Fri, Jul 17, 2015 at 6:05 PM, David Cole dlrd...@aol.com wrote: Attached is a patch file of my first attempt. I can iterate some more on this (better testing, add docs, clarify existing docs, address anybody's comments, submit to stage) next week. Attached now in case anybody wants to try it out over the weekend. David, Awesome - thank you for doing that! (Way faster than I would have been able to set it up). It may be Monday before I can put it through it's paces, but I'll definitely give this a go and also see if I can combine it with the SOURCES target property Brad pointed out to kill two problems with one patch. I'll try to get at figuring out how to set up GLOBAL properties for collecting various types of message outputs and prepare a patch for that on Monday as well, unless someone else gets to it sooner. 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
Re: [cmake-developers] Listing source-tree files encountered
On Fri, Jul 17, 2015 at 11:50 AM, Brad King brad.k...@kitware.com wrote: On 07/15/2015 10:38 PM, Clifford Yapp wrote: 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. Once the list of all targets is available in a global property as discussed in another branch of this thread, then you could loop over that and check the SOURCES target property to get the list of original path specifiers. That would handle almost everything. What would be left for your use case? That sounds like it should work - I hadn't considered the possibilities of the SOURCES target property. Is that property available for custom targets as well? 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] Listing all targets (was: Wrapping functions in CMake)
Attached is a patch file of my first attempt. I can iterate some more on this (better testing, add docs, clarify existing docs, address anybody's comments, submit to stage) next week. Attached now in case anybody wants to try it out over the weekend. Cheers, David C. On Fri, Jul 17, 2015 at 3:03 PM, David Cole dlrd...@aol.com wrote: I think the see also is relevant because it points to another way to get to a whole different set of properties. Perhaps what they're looking for when they stumble upon get_cmake_property is actually target properties, which are only accessible via get_property. While it's relevant, and I think it should remain, I do think it could use some clarification. I'll take a stab at this, and clarify the docs, too, unless somebody else chimes in and tells me wait! I'm doing it already :-) Cheers, David C. On Fri, Jul 17, 2015 at 2:55 PM, Ben Boeckel ben.boec...@kitware.com wrote: On Fri, Jul 17, 2015 at 14:16:34 -0400, David Cole wrote: get_cmake_property is more like strictly well-pre-defined, read only (ish), built-into CMake properties. Note there is no set_cmake_property... What docs are you looking at that you think have a bug...? Help/command/get_cmake_property: get_cmake_property -- Get a property of the CMake instance. :: get_cmake_property(VAR property) Get a property from the CMake instance. The value of the property is stored in the variable VAR. If the property is not found, VAR will be set to NOTFOUND. Some supported properties include: VARIABLES, CACHE_VARIABLES, COMMANDS, MACROS, and COMPONENTS. See also the more general get_property() command. `get_property` has no way (that I see) to ask for the same properties. The whole command docs could use a revamp too (while TARGETS is being implemented to avoid conflicts?). --Ben 0001-CMake-Add-TARGETS-to-get_cmake_property.patch Description: Binary data -- 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
