After parsing the CMake response, we make the configuration variables
table reflect the actual configuration in the build directory. It is one
of our "promises" that we do not break an existing build configuration,
to avoid unexpected rebuilds.
This was not quite true for the "QML debugging and profiling" setting.
When that setting and the actual build directory disagreed, the user
would get a dialog asking for running CMake with additional parameters,
and when running CMake via the button in projects mode or the menu, it
would just change these configuration parameters, potentially leading to
an unexpected complete rebuild of the application.
So, after parsing check if the actual CMake configuration matches our
QML debugging setting, and if not, change the setting to "Leave at
Default", to ensure that we don't mess with the build.
Fix the "Run CMake" button state (in the "Current Configuration") when
changing the QML debugging option, which should become bold, if the
CMake parameters change.
Amends 2577ce8ba1 and fixes the drawback
mentioned there, i.e. setting the build directory of a "Debug" build
configuration to an existing build directory with QML debugging
disabled, will now simply set the QML debugging option to "Leave at
Default" instead of forcing it to "Enabled".
Change-Id: Ie6d4875d59319687d94e44e459ca76038e5813c0
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
... for use in the default build dir template.
Task-number: QTCREATORBUG-26147
Change-Id: I1a32d60e0d5e2db514ac315c48c615c55ccda51f
Reviewed-by: hjk <hjk@qt.io>
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>
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>
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>
... 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>
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>
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>
A tab bar should span completely above the group that it "tabs", and
have no spacing to it. Otherwise there are funny visual artifacts, and
the visual correspondance is not clear.
Add an option for spacing to LayoutBuilder for that.
Change-Id: I5ca9dc713fff95599c9ec1cf90abe8473bc67c2a
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
Reviewed-by: hjk <hjk@qt.io>
Reviewed-by: Alessandro Portale <alessandro.portale@qt.io>
The CMAKE_GENERATOR variable in "Initial Configuration" didn't get
the Kit value after a change in the "Kit Configuration" dialog.
Change-Id: Ieb9d634e2e9b1a5522b189e16bb66f8cea4c63b1
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
Use FILEPATH for CMAKE_C|CXX_COMPILER variables, and PATH for directory
variables like CMAKE_PREFIX_PATH.
Task-number: QTCREATORBUG-27005
Change-Id: I906de43ab97d2dbad0374469c4576d901d2f6339
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
This looks more in sync with other dialogs that we display.
Change-Id: I445da900982b7bdcc12d810e69170b0a7695b30c
Reviewed-by: Alessandro Portale <alessandro.portale@qt.io>
When the user changes or adds new CMake Kit parameters, the changes
are reflected in the Initial Configuration.
Change-Id: Icca1c76749c772e946ff250f94b7965cf7cf9ee8
Reviewed-by: Alessandro Portale <alessandro.portale@qt.io>
The crash scenario:
1. Switch CMake tool in Kit CMake Configuration in Settings
2. Click on the "options" help link
Change-Id: Ifdb2809789748926a5ee0e127db0c87a22efa9dc
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
Reviewed-by: Alessandro Portale <alessandro.portale@qt.io>
This way one could easily jump to the documentation of a CMake
variable e.g. CMAKE_BUILD_TYPE.
Change-Id: I1b348f0a1b6c18f0f7cee29ff6409b43c6263f44
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
Reviewed-by: Alessandro Portale <alessandro.portale@qt.io>
This way a user can quickly find out which options can be used.
Change-Id: I6347759689a4a1431a82ff9414da0c79e357eb45
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
This "Kit Configuration" button opens a dialog with the kit's
CMake settings.
This way a user can change all CMake related settings in the
project's Settings page.
Change-Id: I76b6e69ea7a9b96823f6583aef007cf413410407
Reviewed-by: Alessandro Portale <alessandro.portale@qt.io>
As it turns out changing to selectedRows resulted in having
the keys copied twice to clipboard.
The change would require some code adaptation.
Amends 0020ef7e30
Change-Id: Ie1decd154f7d22825f4d4eecd0bf544ecac7aa26
Reviewed-by: Alessandro Portale <alessandro.portale@qt.io>
The CMake parameters QTreeView has now:
- alternating row colors
- row selection
Both key and value get the same font and foreground stylings.
- bold when the key is new or the value has been changed by user
- italic when the key has been inherited from kit or initial config
- red when there are differences between the inherited value and
the current value
Change-Id: If09bb2c3e25f59938c5f56e6dd0d6817dfe442cc
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
Reviewed-by: Alessandro Portale <alessandro.portale@qt.io>
Now the "Initial Configuration" and "Current Configuration" displays
in red the mismatches between kit / initial value and respectively
initial and current configuration values.
By having a "Apply Kit / Initial Configuration Value" context menu
entry the user can resolve the mismatches if needed.
Change-Id: I2e272821c3ba396cd8a6b7c81e1437cb3fd4bbad
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
Reviewed-by: Alessandro Portale <alessandro.portale@qt.io>
Previously the changes to "Initial Configuration" would be done only
after pressing "Re-configure with Initial Parameters".
Now the settings are saved when the widget is closed:
- a different kit is selected
- a different build type is selected
- project is closed
- switch between build and run settings
This way the changes are not lost.
Change-Id: Ia2c1c10c59bfa101332066205f98684843266f94
Reviewed-by: Alessandro Portale <alessandro.portale@qt.io>
The flush there was as a "hack" for the case:
1. failed initial configuration (CMAKE_GENERATOR as Ninja2)
2. successful configuration
The current configuration would get current items with unexpanded
values e.g.: QT_QMAKE_EXECUTABLE:STRING=%{Qt:qmakeExecutable}
But flush also removed the expanded values of the selected
initial parameters from CMakeBuildSystem::updateInitialCMakeExpandableVars
This is useful when CMAKE_CXX_COMPILER changes or
CMAKE_PROJECT_INCLUDE_BEFORE gets a new path to the new Qt Creator.
Change-Id: I480ce141d043d8ba6001fa47a54b066762b6a128
Reviewed-by: Alessandro Portale <alessandro.portale@qt.io>
updateFromKit() is now called on parsingFinished and the configuration
values that differ from the ones in the Kit's CMake configuration
will be displayed in red.
The "Initial Configuration" page will display the mismatches between
kit's CMake configuration and initial parameters.
The "Current Configuration" page will display the mismatches between
the initial parameters and the current CMake parameters.
The Tooltip is displayed with a bit of more space between values
for more readability.
Change-Id: I6ebfa71951cf979ab08f097befed2d43b74e4d6e
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
This has at least theoretically the potential to get quoting in
"cross" configurations right. Since the consuming side is not ported,
there should be no noticeable differences yet.
Change-Id: I933ded4b1c9645055d3114d53f3d1b95b5c5539c
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
