Handling updates to CMake files

[Aleix Pol]

On Mon, Jun 8, 2015 at 12:09 PM, Andreas Pakulat <apaku at gmx.de> wrote:
> Hi,
>
> On Mon, Jun 8, 2015 at 9:57 AM, Milian Wolff <mail at milianw.de> wrote:
>>
>> 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 ;-)
>
>
> Can't you show it only in case some error happens? In particular if the
> cmake run has been triggered automatically as opposed to by the user.

We definitely can, and it's what we should do.

>
>>
>> > > 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.
>
>
> Oh, ok, I guess I've really lost track on how the CMake support gets the
> needed data out then :|

The plan was to fix cmake instead of implementing all cmake spec
internally in KDevelop. I approached them but my solution was
considered not enough and Stephen provided a much more complete (and
complex) alternative. See cmake-devel mailing list.
At the moment we are only using the few data in the build directory to
populate the project tree.

Aleix