Handling updates to CMake files

Milian Wolff mail at milianw.de
Mon Jun 8 07:57:55 UTC 2015

On Sunday 07 June 2015 22:02:48 Andreas Pakulat wrote:
> Hi,
> 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?)
> Its annoying because it is so slow, but there really is no way around that
> is there? After all any change to any of the files in the project can mean
> include paths changed or flags. Does the generation of the json data also
> happen when just building the project? This is something that works
> relatively well in QtCreator, as it uses a X + CodeBlocks cmake generator
> and hence the codeblocks file gets updated on each build. Since thats
> something that I happen to do quite a bit whenever I chang ethe file
> QtCreator is up-to-date most of the time.

Yes, I also fear there is no way around it. But I asked specifically because I 
think it would be really ugly if every time I edit a CMakeLists.txt, the 
"cmake configure" output view is brought up. Oh how I'd like to have proper 
IDE integration for CMake ;-)

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

As Alexander said, it's not in the json file. I'll implement an easy fallback 
based on the path later on.

Milian Wolff
mail at milianw.de

More information about the KDevelop-devel mailing list