Tobias Hunger wrote:
Hi Mike,
On Thu, Mar 23, 2017 at 8:13 PM, Mike Jackson<imikejack...@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
_______________________________________________
Qt-creator mailing list
Qt-creator@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qt-creator
