Finally getting back to this, hopefully can push to next this week, and have this completed in time for the upcoming 3.4 release.
I have three questions before attempting my first merge-to-next for testing: (1) I see how I can easily move "COMPONENTS" from cmGetCMakePropertyCommand::InitialPass to cmState::GetGlobalProperty because I can access the global generator from cmState as well... To move "VARIABLES" and "MACROS," though, I need access to the correct cmMakefile in which the cmGetCMakePropertyCommand is running. Do I need to pass the cmMakefile instance as a new parameter to cmState::GetGlobalProperty, or is the correct Makefile instance already available from the context of the cmState? (If so, it's non-obvious to me from code analysis...) Steve, Brad? Any input on this question? (2) I will update the documentation of get_cmake_property to say these are all also available via get_property(GLOBAL ... That's the correct intent, right? All calls to get_cmake_property should have exactly the same content as a corresponding call to get_property(GLOBAL? (3) Is anyone concerned about adding a global property with the somewhat generic name "TARGETS" ? Do we care if any projects out there are already doing a set_property(GLOBAL with the name "TARGETS"? The downside of a project doing so would be that when they try to read the value back with get_property, CMake's implementation will overwrite their set values with the list of all available CMake targets, which may be different than what the project had set into the property. Thanks for any feedback, David C. On Mon, Jul 20, 2015 at 9:30 AM, Brad King <brad.k...@kitware.com> wrote: > On 07/17/2015 06:05 PM, David Cole via cmake-developers 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. > [snip] >>> 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. > > get_cmake_property is get_property with the GLOBAL scope, except that > it looks like the special VARIABLES, MACROS, and COMPONENTS properties > are hard-coded into get_cmake_property incorrectly. > > This should all be moved over to cmState::GetGlobalProperty and the > new TARGETS property added there. That method already has special > handling for a few other properties too. > > Also the documentation of get_cmake_property should be updated to > mention "global" properties. > > -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 -- 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
