<div dir="ltr">Hi,<div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jun 8, 2015 at 9:57 AM, Milian Wolff <span dir="ltr"><<a href="mailto:mail@milianw.de" target="_blank">mail@milianw.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Sunday 07 June 2015 22:02:48 Andreas Pakulat wrote:<br>
> Hi,<br>
><br>
> On Sun, Jun 7, 2015 at 6:32 PM, Milian Wolff <<a href="mailto:mail@milianw.de">mail@milianw.de</a>> wrote:<br>
> > Hey all, esp. Aleix.<br>
> ><br>
> > In KF5, we are currently really bad at handling updates to CMakeLists.txt<br>
> > files:<br>
> ><br>
> > - configure is not rerun (do we want that on every change to<br>
> > CMakeLists.txt?)<br>
><br>
> Its annoying because it is so slow, but there really is no way around that<br>
> is there? After all any change to any of the files in the project can mean<br>
> include paths changed or flags. Does the generation of the json data also<br>
> happen when just building the project? This is something that works<br>
> relatively well in QtCreator, as it uses a X + CodeBlocks cmake generator<br>
> and hence the codeblocks file gets updated on each build. Since thats<br>
> something that I happen to do quite a bit whenever I chang ethe file<br>
> QtCreator is up-to-date most of the time.<br>
<br>
</span>Yes, I also fear there is no way around it. But I asked specifically because I<br>
think it would be really ugly if every time I edit a CMakeLists.txt, the<br>
"cmake configure" output view is brought up. Oh how I'd like to have proper<br>
IDE integration for CMake ;-)</blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
> > Furthermore, I wonder whether we should give "best-guess" results for<br>
> > defines/includes. Assume we add a new file to a project (and do not add it<br>
> > to<br>
> > CMakeLists.txt straight away). Currently, this will result in no include<br>
> > paths<br>
> > or defines and thus bad parsing. In KDE4 we used to jump through hoops in<br>
> > the<br>
> > C++ support (and maybe also in CMakeLists.txt?) to return the<br>
> > includes/defines<br>
> > for any neighboring file in the folder which has some information<br>
> > attached. I<br>
> > think we should add that behavior again, but inside the CMakeManager -<br>
> > what do<br>
> > you think?<br>
><br>
> I'm not even sure you need to look at 'surrounding files', just taking the<br>
> include dirs active for the directory should be sufficient in most cases.<br>
> Or are KF5 cmake projects attaching the include dirs to targets these days?<br>
> (Personally I'd still use include_directories() and add_definitions in many<br>
> cases) I'm of course assuming the json data actually has this information<br>
> for each subdir of the project.<br>
<br>
</span>As Alexander said, it's not in the json file. I'll implement an easy fallback<br>
based on the path later on.</blockquote><div><br></div><div>Oh, ok, I guess I've really lost track on how the CMake support gets the needed data out then :|</div><div><br></div><div>Andreas</div></div></div></div>