[cmake-developers] Generating buildsystem metadata from CMake

[Stephen Kelly]

Tobias Hunger wrote:

> On Wed, Apr 1, 2015 at 12:41 AM, Stephen Kelly <steveire at gmail.com> wrote:
>> 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.
> 
> That is not necessary for QtC. Feel free to add this information if
> somebody else needs it.

Ok. I have some ideas of how this could be useful, so I'll see about adding 
it later.

> <snip>
> 
>>> * 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 not necessary for QtC. Feel free to add this information if
> somebody else needs it.

Ok, I think the conclusion is that this is not useful as the built-in 
defines are very likely to change with different compile flags, which are 
very likely to be set in the buildsystem *after* CMake would have checked 
them from the compiler. 

So, I don't think this will be added.

> Creator will parse the compile_flags anyway, so it does not matter to
> me whether some defines/includes end up being hidden in there, but I
> would prefer to get as much of the information separately if possible.
> So please keep the include_directories and compile_defines that cmake
> knows about separate. That is so much nicer to parse than some command
> line, especially when escaping starts to get necessary.

Right. That sounds like an argument for the kind of 'duplication for 
different use cases/approaches' I just proposed:

 http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/12658/focus=12879

>>> 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.
> 
> We do need to know the compiler *binary* (/usr/bin/gcc), but not
> necessarily the complete command line that is run ("/usr/bin/gcc -c
> -Dsomething -I/some/path something.cpp something.o"). We do of course
> need to be sure that we have all the information to generate that
> command line in the form of compile_flags, compile_definitions,
> include_directories and whichever other flags may be relevant.

Ok.

> If you want to log the compiler-defined defines into the Json file,
> then cmake obviously needs to query the compiler for those.
> 
> These defines are heavily dependent on the command line flags you pass
> (e.g. -std=c++11 will set some other defines than -std=c++98). There
> is a long list of options that change the defines set by the compiler.

Right, this is what I temporarily forgot :).

> So that means cmake would need to run the compiler once for each
> possible set of options passed to the compiler during the later build
> steps, so that it can put this information into the meta-data file.
> That seems a bit excessive to me,

Agreed.

> even though creator could probably
> use that information if you did provide it. Currently our
> projectmanagers just query for the compiler defines themselves. They
> have to as currently none of the supported build system provides this
> information.

Right, because it's impractical for the buildsystem to provide it, as you 
wrote.

Thanks,

Steve.