Handling updates to CMake files

[Aleix Pol]

On Sun, Jun 7, 2015 at 6:32 PM, Milian Wolff <mail at milianw.de> wrote:
> Hey all, esp. Aleix.
>
> In KF5, we are currently really bad at handling updates to CMakeLists.txt
> files:
>
> - configure is not rerun (do we want that on every change to CMakeLists.txt?)
> - this way, no compile_commands.json file is updated
>
> ok, but even when we build/configure manually, and compile_commands.json is
> updated, then we do not update the json data at all. dirtyFile() calls
> import() which does *not* create an import job! So no CMakeImport job is
> created and the json data is never updated. This at least should be fixed
> independently of how we want to handle the above.

Yes, it's been on my to-do list for some time, you can look into it.
Or I will, eventually.
I was kind of waiting to see if we're eventually going to get proper
cmake support, but I'm starting to lose faith, TBH.
In fact, let me look into it now, I'll CCMAIL you if I fix it.

>
> 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?

Like somebody replied, it's something far from trivial to implement,
although it can of course be done, since we're wizards over here [1].
I'm unsure it makes a big advantage, maybe you can just use your
energy to poke Stephen Kelly to ready his ultimate IDE integration
approach.

Aleix

[1] http://www.gifvault.com/cinderella-gif-2340.html