Handling updates to CMake files

[Andreas Pakulat]

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.


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

Andreas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20150608/ec8bdbc2/attachment.html>