[cmake-developers] Listing all targets

David Cole DLRdave at aol.com
Mon Sep 14 11:46:49 EDT 2015


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.king at 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


More information about the cmake-developers mailing list