[cmake-developers] Generating buildsystem metadata from CMake

[Stephen Kelly]

Anton Makeev wrote:

> The problem with the following format:
> ---
> "include_directories" : ["/foo", "/opt"]
> "compile_definitions" : ["DEF=\"Foo\"", "OTHER_DEF=1"]
> "compile_flags": [ "-c" ]
> —
> Is that it’s incomplete and cannot be used directly:
> * include directories list misses compiler-defined search paths

CMake gathers those during configure time, and we can add them to the 
metadata too.

> * quote include directories are not distinguishable

CMake does not currently generate -iquote as a result of a user writing an 
include_directories() call. 

Are you asking for that as an option? That would be an independent feature 
request. I'd suggest filing it in the tracker.

Otherwise, the only way CMake currently would pass such options to the 
compiler is if the user specified them in CMAKE_CXX_FLAGS or 
add_compile_options() or similar. 

CMake does not attempt to parse CMAKE_CXX_FLAGS for things which look like 
include directories. That variable is just an opaque string of data from the 
point of view of CMake. It is not clear to me whether you are suggesting 
that CMake should do that. If you do want to suggest that, please file an 
issue in the tracker.

Similarly, CMake does not attempt to analyse the meaning of options 
specified in add_compile_options(). Again, it's not clear to me whether you 
are suggesting a new feature for CMake. If you are, please file it in the 
tracker.

To avoid misunderstandings, please post snippets of CMake code together with 
a description of what information you want CMake to determine from the 
snippet and what metadata it should generate.

> * compiler definition do not include compiler-defined(built-in)
> definitions etc.

CMake does not currently gather those during configure, as far as I know. 
That could be added though.

> That is, to have the complete list of include directories and compiler
> definitions, the IDE will have to call the compiler anyways. And here is
> where it will need the actual compiler’s command line.
> 
> Should we had the full list of include directories (split into groups
> like: <>, quote, and frameworks) and the list of all compiler defines, we
> would not need the compiler command-line at all.

I think I understand what you're saying. However, it would help if you 
related what you write to existing CMake features and snippets of CMake 
code. I assume that you are medium-to-very familiar with CMake features 
already, given what you are working on?

> we’ll need to call the compiler with the correct
> command-line to get some more info like specific compiler features, but I
> guess CMake could do it instead of the IDE).

I don't know what you are refering to, but if you want CMake to record more 
compiler features than what it already does:

 http://www.cmake.org/cmake/help/v3.1/manual/cmake-compile-features.7.html

then please file an issue in the tracker.

The information gathered using the above feature can be added to the 
metadata file.

> Though I don’t this it’s a
> way to go for CMake generation, since the compiler should be called for
> every unique command-line flags and undoubtedly make generation way
> longer. 

It's not completely clear to me what you are suggesting here. Maybe you know 
something I don't know.

Can you be clear about what you are suggesting CMake would have to do for 
each unique command line? I know you are not proposing that CMake should do 
it (you said the IDE should do it lazily instead), but what action are you 
actually talking about? What should the IDE do lazily instead of CMake doing 
it? Invoke the compiler to determine the compiler-defined/built-in include 
directories and definitions? They will always be the same, right? Or are you 
talking about the "-I-" GCC option here and how that clears the built-ins? 
Please be more specific.

Thanks!

Steve.