I have been using the nightlies and the time to open our project
(DREAM.3D) is getting better but still can induce a spinning beach ball
on my macOS 10.10 machine (12 Core Xeon with SSD).
One of the issues that I wanted to make sure that you are also seeing is
the "Multiple Targets" issue where we get executables that are numbered
like DREAM3D,DREAM3D2,DREAM3D3.
There is also an issue with multiple "Source Directory" and "Build
Directory" showing up in each target in the projects view. I have a
feeling that some of this may be how we are using CMake? Our project as
a whole ends up having multiple "project(...)" invocations. Also is
there an implicit assumption the for each "CMakeLists.txt" is a project?
In our plugins we use CMakeLists.txt files BUT they do not have a
"project()" call in them and they are included with "include()" instead
of "add_subdirectory()" which might make a difference.
Thanks for moving the CMake integration forward.
--
Michael A. Jackson
BlueQuartz Software, LLC
[e]: mike.jack...@bluequartz.net
Tobias Hunger wrote:
Hi Mike,
I found a couple of optimization opportunities. Let's see how much
difference these will make:-)
Some smaller ones are in already, but the big one (finding CMakeLists
again after they were inserted) is still open.
On Fri, Mar 24, 2017 at 4:43 PM, Mike Jackson<imikejack...@gmail.com> wrote:
Tobias Hunger wrote:
On Fri, Mar 24, 2017 at 2:04 PM, Mike Jackson<imikejack...@gmail.com>
wrote:
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?
That should not make any difference: Those header files are not ever
passed on to the code model:-) That just gets the sources and include
paths and then figures stuff out itself.
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.
I do not find anything to fix: DREAM.3D opens in< 5s for me.
A couple seconds later (for C++ parsing, Test scanning, etc.) the CPU
usage is down to below 5% on all cores.
Ninja reports only 1351 things that need building though, so maybe I
did something wrong?
I tried again with build -997 and it does seem much faster now. I wonder
what changed between -992 and -997. Do you still see multiple "DREAM3D"
targets on the list? I see DREAM3D, DREAM3D2, DREAM3D3 and a few other
targets within the main project show up like that.
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.
Small stuff inside Creator. E.g. Creator should *always* show at least
the top level CMakeLists.txt file and a broken configuration of
DREAM.3D broke that. Fixed now.
<snip>
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?
No idea:-)
What does the progress bar say when creator is busy? That should give
a hint as to what is going on. As I said: It takes about 5s to open
DREAM.3D on my laptop and that is a considerably less capable machine
than yours.
The beach-ball really prevents anything from being seen. Nothing obvious
that I can see. Is it possible to output something to the "Application
Output" or "Compile Output" widgets that indicates that information is being
gathered from CMake? Or maybe there is a way for me to log that and I just
don't know about it (Most likely..).
Configuring our 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.
I must be doing something wrong then, my machine is much faster than that.
Are you on Linux? Our Core i7-4790K (4.0GHz) will configure in 7 seconds.
The same exact configuration on my 2010 12 core Mac Pro take 41 secs.
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.
I do not think that cmake is the problem here. You know how long it
takes to run cmake on the command line and Creator should never be
slower than that.
Best Regards,
Tobias
I agree (and proved that is the case) it is after cmake is done running when
the project tree is being generated that is taking the most time. I'll try
to get over to the Linux machine and see how long it takes over there.
Mike Jackson
_______________________________________________
Qt-creator mailing list
Qt-creator@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qt-creator
