[Qt-creator] QtCreator 4.3 Beta and CMake 3.7.x Server Mode Slowness

[Mike Jackson]

Tobias Hunger wrote:
> Hi Mike,
>
> On Thu, Mar 23, 2017 at 8:13 PM, Mike Jackson<imikejackson at gmail.com>  wrote:
>> One thing that I notice is that with Server-mode the code completion engine
>> can not find things like #include<QtWidgets/QDialog>  which basically messes
>> up the code completion on the file.This does not preclude the fact that our
>> CMake may be non-optimal and missing some include_directories() and we just
>> have never noticed it before on Visual Studio, Ninja, NMake, Makefiles and
>> Xcode, but none of those use Server-Mode so we may be in new territory.
>
> Well, server-mode does get way better information out of cmake, so
> that is kind of expected:-)
>
> What does the code model say (Tools>C++>Inspect C++ code model)? Does
> it list the expected include directories?

I just noticed that the issue is when I look at a .h file in the editor. 
In the project list the .h file is grayed out and the code model only 
shows a few include paths. Its like the Project Model does not know how 
to handle the .h files because they are not compiled?

>
>>>> My point is NOT to complain since I understand these features are
>>>> experimental and still being developed. If by the the final release the
>>>> slowness is still there, is there going to be a way to turn OFF the CMake
>>>> server mode link if I am using CMake 3.7?
>>>
>>> None is planed.
>>
>> I know it is late, but I would _really_ want to discuss that. Again, if
>> there is time or it would be simple to implement, like a check box in the
>> CMake configuration widget.
>
> I want to get rid of the tealeaf mode as soon as possible. The name is
> fitting: What Creator is doing without server-mode is reading in tea
> leaves, mostly tea leaves that are documented to change meaning at any
> time!
>
> Perpetuating tealeaf mode by having users enable it for newer cmakes
> is definitely not in my interest!

I agree philosophically but there may be a practical side of things. 
Lets see if the issues all get fixed by release of QtCreator 4.3 then I 
really will not have any argument at that point.

>
>> All of our projects are open-source.
>> http://www.github.com/bluequartzsoftware/dream3d. There are other repos that
>> will need to be pulled. I there are some really rough docs that point you to
>> them. We have a bunch of dependent libraries. If you clone
>> https://github.com/BlueQuartzSoftware/DREAM3DSuperbuild that should help
>> build up an SDK for DREAM.3D to use. I have not tested it too much on newer
>> Linux distributions so not sure how well it would behave. You could probably
>> get DREAM.3D to compile without the DREAM3DSuperbuild by just pointing CMake
>> to all the various locations on your Linux machine.
>
> I'm currently trying to set up DREAM.3D for testing:-)
>
> So far I found two smaller issues with creator's cmake support due to
> it -- and I did not even manage to make it build yet:-) What a
> wonderful test project!

Interesting. What were the issues? If you do find issues with DREAM.3D 
or any of its subprojects just let us know or put in an issue at 
GitHub.com. Our use of CMake may not be completely standard or may be 
unexpected. Some of the CMake code has been in there since 2009.

>
>> Just some stats on the project with a full compile of all our Plugins there
>> is something like 2400 compilable files. We do depend on things like Boost
>> and Eigen which are heavily templated which might be the cause.
>>
>> I would also be ok setting up a Google Hangout and screen sharing my machine
>> so you can see what is going on.
>
> Thanks, for the offer. I might take you up on it if I can not
> reproduce the issue locally.
>
>> I jumped on the Qt4.3 bandwagon with CMake 3.7 pretty quickly to test it
>> out. If I remember correctly back in January time frame the speed wasn't
>> noticeably slower. I would have to go pull those versions and start testing
>> to figure out when it really went slow.
>>
>> I restarted with the -settingspath /tmp/foo and the code completion seems to
>> subjectively be faster. THe command-K is definitely faster. Project loading
>> is still slow, to the point where I get the spinning beach ball for about 1
>> minute. This is on a 12 Core (24 Threads) Mac Pro running macOS 10.10.5 off
>> an SATA SSD (850 EVO).
>
> Well, cmake is heavily single-threaded, so all your cores will not
> help with anything cmake-related:-)

So when QtCreator is spinning a beach-ball on macOS and QtCreator is 
only burning 100% is that because CMake is taking a while to do 
something? Configuring out project can take upwards of 30 seconds on 
macOS and Linux and even longer on Windows. You can check the times at 
http://my.cdash.org/index.php?project=DREAM3D, clicking the gear icon in 
the upper right side and selecting Advanced View.

Maybe popping up a dialog if it is taking longer than xx seconds to run 
the CMake part? That way it does not look like it is hung up? I imagine 
for smaller projects this is not a problem because CMake runs fast 
enough on those projects.

>
> Best Regards,
> Tobias


Cheers
Mike Jackson, BlueQuartz Software