Handling updates to CMake files

[Milian Wolff]

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.

Bye
-- 
Milian Wolff
mail at milianw.de
http://milianw.de