[cmake-developers] Generating buildsystem metadata from CMake

[Anton Makeev]

> On 30 Mar 2015, at 21:21, Alexander Neundorf <neundorf at kde.org> wrote:
> 
> On Monday, March 30, 2015 19:04:10 Anton Makeev wrote:
>>> 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.
> 
> 
> Code for detecting the built-in include dirs and definitions is in 
> CMakeExtraGeneratorDetermineCompilerMacrosAndIncludeDirs.cmake. This is used 
> currently by CMakeFindCodeBlocks.cmake and CMakeFindEclipseCDT4.cmake, i.e. 
> the respective extra-generators, and the information is generated into the 
> eclipse/codeblocks project files.
> This could be used here too.
> 
> I don't really understand your second point. Can you elaborate ?

Sure,
'some compilers’ distinguish between “include” and <include> search paths, gcc has -iquote and -I- parameters to specify “include” search path:
https://gcc.gnu.org/onlinedocs/cpp/Search-Path.html

Distinguishing them is necessary to correctly resolve headers inside the IDE.
Additionally, there is frameworks search paths (os OS X), and it’s very important to differentiate them as well.

Here is clang’ list just for the reference:
---
#include "..." search starts here:
#include <...> search starts here:
 /Applications/Dev/Xcode-6.2.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/clang/6.0/include
 /Applications/Dev/Xcode-6.2.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include
 /usr/include
 /System/Library/Frameworks (framework directory)
 /Library/Frameworks (framework directory)
---

Cheers,
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/d8e15c1b/attachment.bin>