[cmake-developers] Generating buildsystem metadata from CMake

[Anton Makeev]

> On 24 Mar 2015, at 00:54, Stephen Kelly <steveire at gmail.com> wrote:
> 
> Tobias Hunger wrote:
>> 
>> How about include_directories, compile_definitions and compile_flags?
>> 
>> So something along the lines of:
>> 
>> "include_directories" : ["/foo", "/opt"]
>> "compile_definitions" : ["DEF=\"Foo\"", "OTHER_DEF=1"]
>> "compile_flags": [ "-c" ]
> 
> Quoting Anton:
> 
> Anton Makeev wrote:
>> The other thing that seems troubling to me is that since file, target,
>> language compiler options are split into different parts of metadata, the
>> IDE need to know exactly how to assemble them back into the compiler’s
>> command line (e.g. what flags go first file’s or language’s), duplicating
>> CMake's logic that may be different from version to version and from
>> compiler to compiler. The exact command line is needed to get the actual
>> and precise defines, include search paths etc. from the compiler.
> 
> Maybe he can chime in with more. I don't really know why the entire command 
> line is needed instead of separate "include_directories" and 
> "compile_definitions" arrays as you and I suggested. Perhaps because that 
> would not include -fPIC for example, which causes __PIC__ to be defined.
> 
> Another item of note is that CMake does not know the compile flags as a 
> sequential container of individual flags currently, but it knows them as a 
> string (that's also why it appears as a string in my generated json 
> currently).

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
* quote include directories are not distinguishable
* compiler definition do not include compiler-defined(built-in) definitions
etc.

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.
(It’s actually not completely true, since 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).
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.
That’s why I think it’s up to the IDE to (lazily) call the compiler when this information is necessary.

Does it make sense or maybe I’m missing something?

>> Parsing things is always error prone. Is that -D for definitions or /D?
> 
> As we can define the format, we could always generate -D and define that as 
> the answer to your question.
> 
> Anyway, let's see if Anton can explain more about the need for the exact 
> command line and whether my suggestion of duplicating the 
> "include_directories" and "compile_definitions" is fine.
> 
>> The compiler flags are definitely needed though. They are used to e.g.
>> decide which dialect of a language are used.
>> 
>> This would keep parsing simple and will also provide all the
>> information we need.
>> 
>> "linker_flags" might also be interesting...
> 
> Yes, something like this is also in the goals for this design.
> 
> Thanks,
> 
> Steve.



Anton Makeev
JetBrains
http://www.jetbrains.com
"Develop with pleasure!"

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2856 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20150330/ada7ca84/attachment.bin>