Get rid of the hardcoded QML Debugging for Debug & RelWithDebInfo from
the project template, because RelWithDebInfo is actually a good
configuration for doing releases (we use it for Qt Creator), and
enabling QML debugging for releases is a bad idea.
Instead enable QML Debugging in Qt Creator for the Debug configuration,
and add a 'Profile' configuration that is 'RelWithDebInfo + QML
Debugging'.
When importing a build, we only set the "QML debugging" option of the
build configuration, if it is enabled in the imported build, even if it
uses CMAKE_BUILD_TYPE=Debug .
One drawback: When not importing a build, but just setting the build
directory of a "Profile" or "Debug" configuration to an existing build,
Qt Creator asks if it should apply "-DCMAKE_CXX_FLAGS=-DQT_QML_DEBUG".
The user can choose not to, but then is asked the next time again, and
it is not obvious that the "QML debugging" option is responsible for
this.
That is somewhat orthogonal to this change though: Even without this
change, if the user changes the QML debugging option from "Leave at
Default" to "Enable", the same happens, and it is also not clear to the
user how to get rid of it. The user might not even have realized that
they changed the option (e.g. on platforms where the mouse wheel cycles
combo box values).
I think the correct solution is to 1. make clearer where the CMake flags
came from in that dialog, 2. allow the user to cancel a build from that
dialog, 3. allow the user to discard these changes (by changing the
setting) from that dialog. But that is for another patch.
Amends 3300182d40
Amends 77fed0b0fd
Change-Id: I95de59473b67c5afd6a53ea7f49838dbaef770d4
Reviewed-by: Artem Sokolovskii <artem.sokolovskii@qt.io>
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
From removing the "first build in temporary directory" mechanics.
The method that would previously switch the build directory from
temporary to real now just ensures that the build directory exists and
passes the input build directory through. Name it encordingly and remove
the confusing return value.
Remove condition that now was always true.
Amends 0e613918b6
Change-Id: I8d4cff23b3fcba895bc7338e7277d44efb46e8e7
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
Before this, if you set "QML debugging and profiling" to "Enable" and
then triggered "Re-configure with initial parameters", it would at first
not have QML debugging enabled, and only at some later point if you want
to re-run CMake with the additional options.
Change-Id: I5e8de7ebadbcb5a44b507ab9b953d4cbd8a3d063
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
Delete the watcher from the handleProcessDone() handler
in order to avoid a circular call to the handler in case the
handler canceled the task.
Delete the watcher also from destructor, prior to canceling
the task.
Fixes: QTCREATORBUG-27564
Change-Id: Ic5859ea159f66106602ed1bf1fc32e439edf28d9
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
Create a QFutureWatcher instead and connect to its canceled()
signal.
Replace some includes with forward declarations.
Change-Id: Ie82bf8902ef8c8d87011809bd14b7db3d4f52179
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
Calling QtcProcess::terminate() doesn't guarantee that
process will be terminated, especially on Windows we may
ofter wait for it forever. Replace the call to terminate()
with close(). After calling close(), the process will sooner
or later be terminated (or finally killed) - that's the job
for ProcessReaper.
Since the current code relies on receiving the finished() signal
after calling a stopping method, we need to call the expected
handler (handleProcessDone()) after calling the QtcProcess::close(),
as afterwards we can't expect receiving any signal for the possibly
running process anymore.
Refactor the code so that we connect do QtcProcess::done() signal
instead of connecting to QtcProcess::finished() signal. This
guarantees that the handler will also be called when process
failed to start. Handle this case in done() handler, too.
Rename CMakeProcess::terminate() into CMakeProcess::stop()
in order to avoid confusion on what method we have chosen to
stop the process in fact. That's the implementation detail.
Get rid of some QFuture related handlings from public API.
Use them directly from inside CMakeProcess d'tor.
Get rid of public state() method, as it seems it's unused.
Increase the responsiveness of small [x] icon of the running
cmake task (reduce the timeout of 500 ms into 50 ms).
Fixes: QTCREATORBUG-27518
Change-Id: I15cac3990079ad1cae0bbe22ac2a6e64cfb659a0
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
A couple of tooltips in Qt Creator, contain rich text (HTML). These
tooltips tend to have line breaks in unfavorable places, making the
content sometimes hard to read.
This is fixed in this change by using: style="white-space:pre"
Another issue with some tooltips is that they show key/value definitions
in a <table>, which, especially with longer keys makes looking up the
value quite hard. Also the length of the key column is dependent on the
(translated) content.
This change implements an alternative: using "description lists" <dl>,
which indent the values nicely independent from the key length.
Fixes: QTCREATORBUG-27553
Change-Id: If047627193413f23d868c52f005f22aa9a0752a9
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
This makes sure that the CMake process is terminated.
Fixes: QTCREATORBUG-27518
Change-Id: Ibe227f6336be312abbe2517af421856463e9c9e8
Reviewed-by: Orgad Shaneh <orgads@gmail.com>
If the user cancelled the file system progress bar, the the
m_allFiles will be null and shouldn't be used.
Fixes: QTCREATORBUG-27499
Change-Id: I92c509f1e66d0968f921ec103fd81631eed9ab38
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
By default xcodebuild does not try create / download a provisioning
profile for a project if a valid one does not exist locally
in ~/Library/MobileDevice/Provisioning Profiles, even if the
Xcode CODE_SIGN_STYLE attribute is set to Automatic.
Starting with Xcode 9, xcodebuild accepts a new
-allowProvisioningUpdates option.
When passed, xcodebuild will request a new provisioning profile
from Apple's servers for the current project and use it during
the build. The provisioning profile is only needed when building
for a real device, not the simulator.
When building an iOS project with qmake, the option is embedded in the
wrapping Makefile generated by qmake, so Qt Creator can simply call
make (which it does).
For CMake, there is no wrapping Makefile, so we need to pass the new
option explicitly as an additional build tool argument.
There might be cases where automatic provisioning is not desired,
which is why there is now a new checkbox in the CMake build step
configuration widget. It's default value is 'enabled', to match
qmake's behavior.
As an implementation detail, isiOS had to be moved to a header file so
it's accessible to both the build configuration and the build step.
Fixes: QTCREATORBUG-26246
Change-Id: Ic80cd965ba095d0ff379e13ad2ffb8c298c9f7c4
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
... by direct use of CMakeConfig::fromFile(). It was only duplicating
checks that are done on the user side already.
Change-Id: Iaf5e89c924c2b0a9080db9fe160970bbf6e33154
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
... for the repeated stanza
setParametersAndRequestParse(BuildDirParameters(this), ...)
Change-Id: Ibb6e8346a786bb9d6905de7facb374f750e561d3
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
This adds the build system feature that allows Qt Creator's libraries
and plugins to be compiled statically.
Fixes some symbol clashes when all plugins are linked into the same
executable.
Support for actually loading static plugins will be added in a separate
commit.
The feature is controlled by QTC_STATIC_BUILD which by default is OFF.
Change-Id: I1fab7953c43e42dc75619e35660029ee067106df
Reviewed-by: hjk <hjk@qt.io>
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
... from CMakeBuildConfiguration to CMakeBuildSystem.
Less back-and-forth this way.
Also, prefer plain buildConfiguration() over cmakeBuildConfiguration()
back-pointers.
Change-Id: Ie1341302ecc10e53d71ca68b7b6eb5f46cfdad5f
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
Most inclusions of idevice.h inside other headers are
required just because of IDevice::Ptr or IDevice::ConstPtr
was used there. Unfortunately, since these "using"
are defined inside a IDevice class, we just can't
forward declare IDevice::Ptr nor IDevice::ConstPtr.
Instead, create a separate header that defines
IDevicePtr and IDeviceConstPtr while having IDevice
forward declared. Redefine IDevice::Ptr/ConstPtr
inside IDevice to use IDevicePtr/IDeviceConstPtr.
Now, instead of forward declaring a IDevice::Ptr
it's sufficient to include the idevicefwd.h.
This drops the number of files being recompiled
after touching idevice.h from ~770 to ~210.
Change-Id: Ib6f2982aa0761fb4cd6593badb9c3c0c527ea535
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
Reviewed-by: hjk <hjk@qt.io>
These calls would make interactive changes useless and the fake hide
event would remove the interactive flag which would prevent the user
from doing any changes.
Fixes: QTCREATORBUG-27257
Change-Id: I80a53d8955ac2329c726989954f1d910e93b3501
Reviewed-by: Alessandro Portale <alessandro.portale@qt.io>
* Added returning the Id after detecting CMake so it can be set in the autodetected kit
* Trying to keep autodetect from adding the same Qt installation twice if qmake is linked in /bin and /usr/bin
* Added FIXME for RunControlPrivate::runConfiguration as it is used after free in rare cases
* Fixed IosCompilerDetector to not just run if a device is set
* Fixed QnxCompilerDetector to not just run if a device is set
* Fixed auto-detected debuggers not being set as auto-detected, as they now can be removed from the device screen
Change-Id: Ia7772c454d70e147e4326efacc4a6a888fa26782
Reviewed-by: hjk <hjk@qt.io>
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
So far we only looked at a target and added all paths of actually linked
libraries to the ((DY)LD_LIBRARY_)PATH, if the "Add build library search
path" option is on (the default).
That often is fine, but
- if the library to link to is only given as a library name, not a path
and not a CMake target, then CMake file-api doesn't give us a path to
the library either
- on Windows, where the .lib is needed for compiletime linking, but the
.dll is needed for runtime linking this only helps if the .dll was in
the same directory as the .lib
We already have a hack on Windows, if the directory ends in /lib, that
we also add /lib/../bin, but that again only helps for that specific
layout.
Instead actually add the "build library search path", by adding the
directories from target_link_directories, even if no libraries are
linked from there. This fixes the "linked only by name" issue, and
allows users to add a build library search path to the .dll too, and
have that used by Qt Creator for running the application.
Fixes: QTCREATORBUG-27201
Change-Id: I7b9210b791b4dae3a6d1747ff36e4b82235db2f9
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
The code was not filtering empty configuration items
that were the result of bad string input like:
-DMY_KEY:PATH/some/path/but/no/equal/sign
Amends a2a8f56b6e
Task-number: QTCREATORBUG-27237
Change-Id: Ic307eceb66dc0e00b073c9aabb04fe70a223cf08
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
The ProjectExplorer::Task::Error will result in having
m_kitErrorsForProject in targetsettingspanel.cpp which in
TargetItem::updateSubItems() recreates the build settings page.
By reporting the CMake project loading as Task::Warning the above
case is avoided the project build settings page is not
disappearing anymore.
Change-Id: Ib2523e6ea86fe5ad6e4bbee4e101b47cb350a68d
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
There were cases when an empty "-D" CMake command line parameter would
be genered, resulting in a failed CMake project configuration.
Task-number: QTCREATORBUG-27256
Fixes: QTCREATORBUG-27237
Change-Id: Ic26c9dfe72db154cd76fdcc913eb7fe623b3123c
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
Also when reading settings. Check was there for writing already,
and possibly should not exist at all, other kit settings are not
purging at that stage.
Change-Id: Ia052efd5a791f4a86be3d26a61ebeb94d506b012
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
More friendly to docker.
Change-Id: I3eeb859cc880fa24c2b1c74caf5a06ec4f27cb2f
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
CMake fails if it has -DCMAKE_GENERATOR:STRING=CodeBlocks - Ninja
It expects separate values:
-DCMAKE_EXTRA_GENERATOR:STRING=CodeBlocks
-DCMAKE_GENERATOR:STRING=Ninja
Fixes: QTCREATORBUG-27060
Change-Id: Ia2b5bdc425e569118d689b7223fbef5f953d98a7
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
- configure with QTC_USE_NEW_MIMEDATABASE to switch to the new one in
utils/mimetypes2/
- added utils/mimeutils.h header for the Qt Creator specific static
wrappers, that also includes the "public" headers for MimeType et al
from the new or old implementation, depending on configuration
- change all utils/mimetypes/ includes to utils/mimeutils.h
- move the implementation for the wrappers to
utils/mimetypes(2)/mimeutils.cpp
- also move the MimeDatabase declaration in the "old" implementation
back to utils/mimetypes/mimedatabase.h
Change-Id: Ie8de229c035d6cd9a5e4739dc0fa78d9c17228e3
Reviewed-by: Jarek Kobus <jaroslaw.kobus@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
