Handling updates to CMake files

[Alexander Richardson]

Hi,

>>
>> Furthermore, I wonder whether we should give "best-guess" results for
>> defines/includes. Assume we add a new file to a project (and do not add it
>> to
>> CMakeLists.txt straight away). Currently, this will result in no include
>> paths
>> or defines and thus bad parsing. In KDE4 we used to jump through hoops in
>> the
>> C++ support (and maybe also in CMakeLists.txt?) to return the
>> includes/defines
>> for any neighboring file in the folder which has some information
>> attached. I
>> think we should add that behavior again, but inside the CMakeManager -
>> what do
>> you think?
>
>
> I'm not even sure you need to look at 'surrounding files', just taking the
> include dirs active for the directory should be sufficient in most cases. Or
> are KF5 cmake projects attaching the include dirs to targets these days?
> (Personally I'd still use include_directories() and add_definitions in many
> cases) I'm of course assuming the json data actually has this information
> for each subdir of the project.
>
The compile_commands.json is an array of elements like this:
{
  "directory": "/foo/bar/build",
  "command": "/usr/bin/clang++  -foobar  -o foo.cpp.o -c /foo/bar/foo.cpp",
  "file": "/foo/bar/foo.cpp"
},
There is no such information at the directory level, but I guess we
could just pick one file that is in the same directory as an estimate.
Not having any information on include paths seems a lot worse to me
than an estimate should be right as long as there aren't multiple
targets with completely different compiler arguments being built in
the same directory.

I seem to remember reading something about CMake generating IDE
friendly JSON metadata, has anything happened regarding that?

Alex