It's what the base class wants, and follows run and deploy precedence.
Change-Id: I26eff43337851702417e7e4284fc390b904060f6
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
The build list names are always the ones determined from the
build list id. No need to do that on the caller side.
Change-Id: Icc21ef355de535af21215819fe04daa76fed0d9c
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
This follow the rough pattern of recent *RunConfigurationFactory changes
for build and deploy configurations.
- Collapse the two lines of constructors similar to what
890c1906e6 did for RunConfigurations
* Deploy* was purely mechanical
* Build* ctors are split in connects() in the ctor body
to create "empty shell for clone" etc
and build step additions in initialize() functions which
are only used in the create() case.
-- Allows to collapse the shared 'ctor()' functions, too.
- Move FooBuildConfigurationFactory::create() implementations
to FooBuildConfiguration() constructor. That was a strange
and unneeded ping-pong between factories and objects, and
furthermore allows one level less of indirection (and for a
later, left out here, some reduction of the
FooBuildConfiguration interfaces that were only used to
accommodate the *Factory::create() functions.
- Most {Build,Deploy}Configuration{,Factory} classes had a canHandle(),
but there wasn't one in the base classses. Have one there.
- Most canHandle() functions were checking simple restrictions on
e.g. project or target types, specify those by setters in the
constructors instead and check them in the base canHandle()
- clone() is generally replaced by a creation of a "shell object"
and a fromMap(source->toMap()), implemented in the base, there
are two cases left for Android and Qbs that needed(?) some extra
polish
- generally use canHandle() in base implementation, instead
of doing that in all Derived::canFoo()
- as a result, canCreate/create/canClone/clone reimplementations
are not needed anymore, keep the base implementation for
now (could be inlined into their only users later), but
de-virtualize them.
- Combine Ios{Preset,DSym}BuildStepFactory. There was only one
'dsym' build step they could create.
- Split the 'mangled' id into the ProjectConfiguration subtype
specific constant identifier, and a QString extraId() bit.
Only maintain the mangled id in saved settings.
- Make ProjectConfiguration::m_id a constant member, adapt
all constructors of derived classe.
Not done in this patch:
- Finish possible cosmetic changes on top
- Add a way to specify restrictions to supported Qt versions
(used in Android/Ios), as the base implementation does not
depend on the qtsupport plugin
- Combine the QList<X> availableFoo() + createFoo(X) function
pairs to somthing like a direct
QList<struct { X; std::function<X()>; }> fooCreators()
to avoid e.g. the baseId.withSuffix() <-> id.suffixAfter(base)
pingpong
- Remove the *Factories from the global object pool
- Do something about priority(). Falling back to plain
qmake in android+qmake setup is not helpful.
Change-Id: I2be7d88d554c5aa8b7db8edf5b93278e1ae0112a
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
This builds on top of 08677c0b01 and
fixes one more code path to go through a common entry/exit point.
Change-Id: I1d00fa9242f247028e5d3b0ef3b5fe1d3f4cb03d
Reviewed-by: hjk <hjk@qt.io>
Reviewed-by: Tim Jenssen <tim.jenssen@qt.io>
The directory tree scanner and the project parsing work independently of
each other. Add logic to combine these two sets of results into one
parsing state.
Change-Id: I46e94f0e866b40ee7225235c536c742cecf11b45
Reviewed-by: Tim Jenssen <tim.jenssen@qt.io>
Also, add context to connect() expressions where we are or were
capturing "this".
Change-Id: I6e006ba6f83d532478018550d148ee93eca59605
Reviewed-by: Tim Jenssen <tim.jenssen@qt.io>
Reviewed-by: hjk <hjk@qt.io>
Get rid of duplicated code to do such signaling in derived Project types.
Change-Id: I26914a1d751d72ee65c15a7943e0e7f34978f042
Reviewed-by: Tim Jenssen <tim.jenssen@qt.io>
When the cmake configuration changes, BuildDirManager checks whether
the new configuration differs from the current configuration.
In case of differences a dialog is opened and the user must decide if
the changes shall be applied or rejected.
When the user changes the cmake configuration in the projects page the
dialog will open as well. This is unencessary since the user already
decided to apply the changes.
Let BuildDirManager not check for changes if the configuration was
changed by the user via the projects page.
Change-Id: I736ee7f4dee99fe707f2931c73b287231b1daa1d
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
This triggers the logic in Project to show the top level project
file in the project tree.
Remove similar logic in CMake.
Change-Id: I2bfdd3f5e3d4126910a3feb480cec5ef689954ed
Reviewed-by: Tim Jenssen <tim.jenssen@qt.io>
Reviewed-by: Florian Apolloner <florian@apolloner.eu>
Do not try to update project data when an error occurred in server-mode.
Change-Id: I6a1cf4b6e79fd6ddf5329195861f34cd7f1ca44d
Reviewed-by: Florian Apolloner <florian@apolloner.eu>
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Do not update the existing project tree anymore: Start a fresh one
and throw the old one away.
Change-Id: Ifabe293b6ca668b0672516a6d81acd5346d98fe5
Reviewed-by: hjk <hjk@qt.io>
To avoid repeating the 'MimeDatabase mdb; mdb.something(); ' mantra
all over the place.
Change-Id: I4bfef62e73275a991455141671d6071162788e9d
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
Make sure the buildconfiguration is disabled while parsing and that
it becomes enabled again after an error in CMake is fixed.
Change-Id: Iec919e3c74c465a14ebb87adb9af142537823f00
Reviewed-by: Tim Jenssen <tim.jenssen@qt.io>
${AnyProject}::updateCppCodeModel() did two potentially not that cheap
operations in the ui thread:
(1) Querying the MimeDatabase for the mime type for the source files of
the project. In 99.9% of the cases no files need to be read for
this as the file extension will resolve the type. The expensiveness
comes from the sheer number of files that can occur.
(2) Calling compilers with the "(sub)project's compiler command line"
to determine the macros. While the caches avoid redundant calls,
the number of the unique compiler calls makes this still a
ui-freezing experience.
These two operations are moved into a worker thread. For this, the
expensive compiler calls are encapsulated in thread safe lambdas
("runners") in order to keep the "mutexed" data minimal. The original
API calls of the toolchains are implemented in terms of the runners.
While adapting the project managers, remove also the calls to
setProjectLanguage(). These are redundant because all of the project
managers already set a proper value in the constructor. Also, currently
there is no need (client) to report back detection of C sources in
project parts. This also keeps CppProjectUpdater simple.
There is still room for improvement:
* Run the compiler calls in parallel instead of sequence.
* Ensure that the mime type for a file is determined exactly once.
Change-Id: I2efc4e132ee88e3c8f264012ec8fafe3d86c404f
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
Add helpers to deal with CMakeBuildTypes and to map them to
BuildConfiguration::BuildTypes.
Change-Id: I03ce9e83b5d044c3d94d29c44cc0a28560b206f6
Reviewed-by: Tim Jenssen <tim.jenssen@qt.io>
This makes sure they need to copy whatever they need.
Change-Id: I767ac0c5f54ca1f9f46acdefe4bd7fea35657312
Reviewed-by: Alexander Drozdov <adrozdoff@gmail.com>
Reviewed-by: Tim Jenssen <tim.jenssen@qt.io>
Project source tree is a same for all build configurations so it is
a good idea to keep it persistent between CMake runs, configurations
switches and so on. It safes a lot of time for big projects.
Move more operations to the scanner thread:
- Nodes filtering: skip .user files on top level of the project, skip
well-known extensions and octet-streams: In most cases these are not
required to be shown in the project tree.
- Nodes sorting
Fix small memory leak: we have .user in the scanner result. After this
node filtered out, but is not feed (old code at the
BuildDirManager::generateProjectTree()). Now .user file skips during scan
without memory allocation at all.
Allow user manually rescan project tree by call Build -> Rescan project
tree. It runs CMake and Tree Scanner together: in most cases only CMake
run requires but time to time (VCS update) full rescan also required.
Change-Id: I4a6e6c897202da557509291c79932dd7751860e5
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
This triggers the fallback mechanism which will make sure the CMakeLists.txt
file will be displayed.
This used to fail since one empty folder was left over in the project.
Task-number: QTCREATORBUG-17383
Change-Id: I867fd9039bc5df805ff5174ec49084bbcf688824
Reviewed-by: Tim Jenssen <tim.jenssen@qt.io>
This fixes saves memory and fixes some update issues with the cmake
configuration, where the three layers of caches used to interfere
with each other.
Task-number: QTCREATORBUG-17360
Change-Id: I5564bbe46ca8de6b38dd710100bfc18fad98eac5
Reviewed-by: Tim Jenssen <tim.jenssen@qt.io>
removeDuplicates keeps the first instance, so pass in the project
configuration first.
Change-Id: I2549b8043905687fecc3b690f1d54456c42a4cf3
Reviewed-by: Tim Jenssen <tim.jenssen@qt.io>
Only the original one is implemented so far, but at least
in theory backends for retrieving data from cmake can now
be switched at runtime.
Change-Id: Id73a81c7d40f078be95defd30a38511dca3a3720
Reviewed-by: Tim Jenssen <tim.jenssen@qt.io>
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
CMake provides "hack" for cmake-gui, that allows set options variants
and select then from drop down list. Allows Qt Creator re-use this
solution.
See:
- https://blog.kitware.com/constraining-values-with-comboboxes-in-cmake-cmake-gui/
- http://blog.bethcodes.com/cmake-tips-tricks-drop-down-list
Drop down values can be added to option via:
SET_PROPERTY(CACHE OptionName PROPERTY STRINGS Option1 Option2 Option3)
This solution should not restrict to provide any other value, it
provides only suggestion for user to select one of prdefined values.
Change-Id: I8fc52155775f1e04979db8206bb42363df9359e8
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
Continue to concentrate all the code reading random cmake files in
BuildDirManager. Now the task is to clean up the code, make it less
dependent on values it should not depend on (kits, etc.), make it
handle changes better and finally add another implementation that
uses the cmake server mode to extract the data.
Change-Id: I533625e376b969b64287bc205bd2e4be7a605306
Reviewed-by: Tim Jenssen <tim.jenssen@qt.io>
Make sure to run cmake *before* cmake --build when cmake files just
got saved. This helps e.g. when editing CMakeLists.txt files and the
hitting "Built" and "Save all" (or "Always save before build").
Task-number: QTCREATORBUG-16187
Change-Id: I16b1d02eb342a447003380946ce7a9d785476a0e
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
This will make it easier to introduce a new type of BuildDirManager
to accommodate cmake server-mode.
Change-Id: I989aab9df44dff1cfdff226ef97bb30bb092ffdd
Reviewed-by: Tim Jenssen <tim.jenssen@qt.io>
This is in preparation for having support for cmake's server
mode.
Change-Id: I6cc04fe7c5132c491c3f3c0f46560b8ad88808e8
Reviewed-by: Tim Jenssen <tim.jenssen@qt.io>
If ProjectMacroExpander doesn't resolve it we fall back to the generic
ProjectExplorer resolution, which is likely to pick the wrong project.
Task-number: QTCREATORBUG-16724
Change-Id: I201b722c5fe184905f744a1f344ec46941f92ae3
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
Rip out QFileSystemWatcher and use Qt Creators IDocument for file
watching instead. The latter properly delays any action till creator
gets focus again.
Task-number: QTCREATORBUG-16354
Change-Id: Ibb71963416b09712a80ee95347425550453b7fd4
Reviewed-by: Tim Jenssen <tim.jenssen@theqtcompany.com>
Sometimes cmake changes the type of random settings to INTERNAL.
This change keeps them visible even then.
Change-Id: Icd6bf26b8e2cb031b76bbba8bf0aac70c349fb7b
Reviewed-by: Tim Jenssen <tim.jenssen@theqtcompany.com>
