[cmake-developers] cmake -E capabilities

[Stephen Kelly]

Tobias Hunger wrote:

> Hello CMake Developers!
> 
> As laid out in the last mail thread about daemon-mode in CMake (for your
> reference:
> http://public.kitware.com/pipermail/cmake-developers/2016-June/028777
> .html ), Stephen and me agreed that we needed a way for IDEs to figure out
> which generators are available to cmake and more static information built
> into CMake.

Here's a gmane link to the thread for reference:

 http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/16782

> There is actually a bug report about the need for this feature here:
> https://gitlab.kitware.com/cmake/cmake/issues/15462
> 
> This is my attempt to solve the issue:
> https://github.com/hunger/CMake/commits/cmake-capabilities

Thanks for working on this.

> The output looks like this:
>> cmake -E capabilities --pretty-print
> {
> "generators" : [
> {
> "extraGenerators" : [],

Interesting. I didn't realize the "Watcom WMake" generator does not work 
with 'extra' generators.

> "KDevelop3",

<off topic> This generator should probably be removed/hidden by now. It has 
confused users of more-recent KDevelop versions.

> What do you think? What else should we report here?

It looks like a good start. The intention of the output is to satisfy needs 
that consumers like you have, and I guess it does have what you need.

> Compared to the bug report mentioned above the fields "multiconfig" and
> "recursive" are missing. I could not figure out how to get that
> information:-/

When I made the example in the issue tracker, 'recursive' meant 'you can cd 
to a directory and run the CMAKE_MAKE_PROGRAM there'. At the time, it was 
possible to do that when using the Makefiles generator, but not the Ninja 
generator. 

I think that capability has since been added for the Ninja generator, but I 
don't know if it is possible with the Xcode and VS generators.

Would that be a useful thing to expose here in your view?

> I would also welcome some code review on the patch. 

1) For consistency you should change 

 GetRegisteredGenerators

to 

 this->GetRegisteredGenerators

whether that is a preferred style is orthogonal to the fact that it's 
consistently used in cmake code.

2) CMake has to build with toolchains which do not provide 
std::unordered_map. See uses of CMake_HAVE_CXX_UNORDERED_MAP for existing 
code which uses either std::unordered_map or std::unordered_map. (Yes there 
is room for improvement there, but such improvement is orthogonal to your 
branch).

3) Similarly, CMake has to build with compilers which do not support 
cxx_range_for or cxx_auto_type. For the cmServer implementation that may or 
may not be the case, but within the cmake class, that's the way it is.

4) It seems that the 

 this->Generators

member of the cmake class has the names of all generators (without 'extra' 
generators). It seems unfortunate to not use that container and instead 
parse the names out of the names from the GetRegisteredGenerators call by 
splitting on the ' - '. It leads to hard coded magic expressions like 
'separator + 3', so it should be avoided if possible.

Is there another way of determining the extra generators supported by a 
given generator and avoiding parsing a string which we just generated? Can 

  const std::vector<std::string>& supportedGlobalGenerators =
    extraGenerator->GetSupportedGlobalGenerators();

be used somehow? Can you first loop over this->Generators to get the 
'normal' generators, then loop over the extra generators, call that method 
to match things up and output the result?

Or would it make sense to refactor the container members in the cmake class 
themselves to make this information more easily available for this use-case?

5) You use the term 'appendix' for the version, but 'suffix' is the more-
commonly used name for that concept.



Thanks,

Steve.