Add qmake2cmake[.bat] wrapper scripts that can be used to convert user
projects to CMake. For now, user projects are internally handled as Qt
examples with one difference: the generation of example-specific
installation code is suppressed.
Fixes: QTBUG-98655
Change-Id: I1a57f6d12efe0bdf383592ab33682a611692db80
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
This function does not handle installation.
Change-Id: I02fdc244f49b5935aa1ac51bff8a25970ad3a335
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
This makes the QT_VERSION_(MAJOR|MINOR|PATH) variables available.
Task-number: QTBUG-98852
Change-Id: I7e40f2a7ac09975ce21e45cda384af928e1fa629
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
...and write a separate find_package(Qt6 OPTIONAL_COMPONENTS Foo Bar)
call for those.
Task-number: QTBUG-96799
Change-Id: I3386487774c386edde6767dca92ce433bfed906e
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
We prefer it when the CMakeLists.txt project files for examples use
qt_add_qml_module() when adding resource files, rather than
qt6_add_resource().
A bit of refactoring was needed to re-use the code that extracts
resource information from the .pro file.
The new function write_qml_module is now responsible for writing
qt_add_qml_module calls.
Task-number: QTBUG-96799
Change-Id: I74dc2d681dcf4fc848e1147b3232ce9a9e0946c9
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
For example projects, change the generated project() call to
project(foo VERSION 1.0 LANGUAGES CXX)
Some CMake API derives default values from the project version, and it's
generally advisable to set a project version number.
The version number is read from qmake's VERSION variable. That's
actually a target version number, but it might be the right thing in
most cases. Fall back to version 1.0 if VERSION is not set.
Task-number: QTBUG-96799
Change-Id: Ia0c551cf62621eb217e1dd541dcbd8945f78138e
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
...to have a consistent baseline for further improvements.
Change-Id: Iba8e83a7a5cf5ca0cdf509f79e7d2dc2d8f42fec
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
To tool generates calls to qt6_add_resources instead, and we don't want
to promote the usage of CMAKE_AUTORCC.
Task-number: QTBUG-87643
Change-Id: I58458416514949a6ffc9b93c7eb6d24bc2ed01ca
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Since commit f3c7d22dd0 we do not use
libraries from /usr/local and other non-system locations on macOS. But
our configure tests still did. This led to discrepancies between
find_package calls in configure tests and the Qt project itself.
Mentioned commit removed /usr/local and friends from
CMAKE_SYSTEM_PREFIX_PATH. But we can't pass this variable to the
configure tests, because CMake sets it up and overwrites our value.
Pass CMAKE_SYSTEM_PREFIX_PATH and CMAKE_SYSTEM_FRAMEWORK_PATH as
QT_CONFIGURE_TEST_CMAKE_SYSTEM_{PREFIX|FRAMEWORK}_PATH variables to
tests.
Tests with separate project files that call find_package() must add code
like this after the project() command:
if(DEFINED QT_CONFIGURE_TEST_CMAKE_SYSTEM_PREFIX_PATH)
set(CMAKE_SYSTEM_PREFIX_PATH
"${QT_CONFIGURE_TEST_CMAKE_SYSTEM_PREFIX_PATH}")
endif()
if(DEFINED QT_CONFIGURE_TEST_CMAKE_SYSTEM_FRAMEWORK_PATH)
set(CMAKE_SYSTEM_FRAMEWORK_PATH
"${QT_CONFIGURE_TEST_CMAKE_SYSTEM_FRAMEWORK_PATH}")
endif()
Adjust pro2cmake accordingly.
Task-number: QTBUG-97076
Change-Id: Iac1622768d1200e6ea63be569eef12b7eada6c76
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Previously pro2cmake assumed that all .pro were internal Qt projects
like qtbase/src/corelib.pro and generated private api calls like
qt_internal_add_module().
Public CMake API calls (like qt_add_executable) were only generated if
an --is-example command line flag was passed to the script or if the
.pro file was located under the examples subfolder of a qt repo source
directory (indicated by the presence of a .qmake.conf file).
Change the logic to always generate public CMake API code by default,
unless a .cmake.conf/.qmake.conf file is encountered with a valid repo
module version inside, in which case apply the old heuristic of
checking for the ./examples subfolder.
The intention is to have a sensible default so that Qt users can use
the script to more easily migrate their qmake projects without having
to explicitly specify the --is-example flag.
Pick-to: 6.2
Task-number: QTBUG-96799
Change-Id: I38f4f1b349a5b9688cf7bc5914d4fde72e660a98
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Adapt to fb656c036d which removes
.qmake.conf files in repos by searching for either .qmake.conf or
.cmake.conf.
The locations of those files are only used to compute relative paths
based on the directory where the conf file is.
For now, remove the warning if a conf file is not found, because we
intend to change the script to generate user project code by default,
instead of Qt internal project code and the warning looks scary.
Pick-to: 6.2
Task-number: QTBUG-96799
Change-Id: I301e93d2ce5c05a52877eb6ed9eb9cee54fc5b15
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Introduce a new macro qt_internal_return_unless_building_tools which
simply calls return() if tools are not built. This macro is supposed to
be called after qt_internal_add_tool().
Using this macro avoids having to special-case code for when
qt_internal_add_tool() creates imported targets in cross-builds.
Adjust pro2cmake accordingly.
Task-number: QTBUG-85084
Change-Id: I9e1c455c29535dd8c318efa890ebd739c42effc1
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Needed for subsequent change that will check and error out if the
version is lower than 3.16. We do that to ensure all policies
introduced by CMake up to version 3.16 have their behavior set to
NEW.
Pick-to: 6.2
Task-number: QTBUG-95018
Change-Id: Ieaf82c10987dd797d86a3fd4a986a67e72de486a
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
pro2cmake.py:458:5: F841 local variable 'is_parent_path' is assigned
to but never used
Pick-to: 6.2
Change-Id: I1c61efe5cf568fa0c99b07eed28b93d3444a5fac
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
This patch will slightly change the output of CMakeLists.txt files that
are generated for examples.
* set_target_properties() will no longer be added to the top-level
scope. If the WIN32 and MACOSX_BUNDLE properties should be added,
they will instead be added to qt_add_executable().
* The version in cmake_minimum_required() will now be 3.16, rather than
3.14.
Pick-to: 6.2
Change-Id: I79e1865dace5538d2b7ff264da02f9e28a655ae9
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Modify pro2cmake to add the 'Private' suffix to the internal module
name by default.
Change-Id: Ia7b2fce387fad5f207a7379ac738173ff9262071
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The BASE argument of qt_add_resources now denotes the root point of the
alias of the file. Before, BASE was merely prepended to every file that
got passed to qt_add_resources.
Old behavior:
qt_add_resources(app "images"
PREFIX "/"
BASE "../shared"
FILES "images/button.png")
Alias is "../shared/images/button.png", and pro2cmake generated
QT_RESOURCE_ALIAS assignments to fix this.
New behavior:
qt_add_resources(app "images"
PREFIX "/"
BASE "../shared"
FILES "../shared/images/button.png")
The alias is "images/button.png". No extra QT_RESOURCE_ALIAS assignment
is needed.
The new behavior is in effect for user projects and for Qt repositories
that define QT_USE_FIXED_QT_ADD_RESOURCE_BASE. Qt repositories will be
ported one by one to this new behavior. Then the old code path can be
removed.
Pick-to: 6.1
Task-number: QTBUG-86726
Change-Id: Ib895edd4df8e97b54badadd9a1c34408beff131f
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
This patchset adds the bits needed for manual tests to work standalone.
Amends ebaa1c15a101579d9296336491e36c63b979f18d
Pick-to: 6.1
Task-number: QTCREATORBUG-25389
Change-Id: Ifc70391bda2a3eea3c7492a58353a703cdc3114c
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Use PROJECT_VERSION instead of CMAKE_PROJECT_VERSION when setting the
version of a qml module, which extracts the version of the latest
project() call rather than the top-level one.
Using CMAKE_PROJECT_VERSION caused issues in top-level builds where
the qtdeclarative version is 6.2, but the top-level project version is
still 6.1 and hasn't been updated to 6.2, causing qml module import
errors.
This was probably an oversight during initial implementation of qml
support in pro2cmake.
So projects that define qml modules should be adapted accordingly.
Amends cce8ada814
Amends 28fff4a551
Pick-to: 6.1 6.0
Task-number: QTBUG-92861
Change-Id: I494784694e997501a5bc4fd0c0eac458ddc248aa
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Modules that are ported for dev should get this version now.
Change-Id: I11d47504f163798d53c51e56ef978edaa711d93a
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
This is needed for the qtimageformats build with bundled libwebp.
Change-Id: I4d32392d7362f254e9633197497b6d78e12da559
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
write_library_section traverses the parent/child hierarchy of scopes to
determine whether the scope belongs to a public Qt module. This doesn't
work for scopes that stem from included .pri files, because each
included file has its own parent/child hierarchy.
We already have an include scope hierarchy in the form of
Scope._included_children, but lack a way to get to the including
scope.
Add Scope._including_scope and adjust the is_public_module calculation
to take that into account after hitting the top of the parent/child
hierarchy.
Pick-to: 6.0
Change-Id: I8fee1cfbf048e7afc6783b0a52eaca75be17072f
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Generate copy and installation rules for AUX_QML_FILES entries.
These are usually handled by mkspecs/features/qml_module.prf.
For the purposes of unblocking the Designer team, instead of creating
AUX_QML file specic functions that would handle installation, generate
qt_copy_or_install() rules.
To ensure installation destination is correct, we need to group file
paths by base directory and specify those in the DESTINATION
parameter. Otherwise the file hierarchy would be flattened.
This is usually handled by file_copies.prf and the equivalent qmake
install mechanism. In CMake we need to handle it manually.
Also detect usage of wildcards to ensure we use globs for
installation.
Task-number: QTBUG-87818
Change-Id: I8a5db445274fb670d90cf90b38598a6b3326bc44
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Modify pro2cmake converter to add extra argument to
qt_internal_add_plugin. DEFINE_IF FALSE is added to generic plugins
those had "PLUGIN_EXTENDS = - " specified in .pro files.
Fixes: QTBUG-87861
Change-Id: I9269df19a32a088f5261f50e7ffff6d29c3d605f
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Change-Id: I47504d6c032c9a6ace7440580f0081cc5f254038
Reviewed-by: Maximilian Goldstein <max.goldstein@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The CONFIG_MODULE_NAME option to qt_internal_add_module is used to
specify what the name of a Qt module's pri file should, as well as
some of the key names assigned in that file, as well as what should be
passed to QT += in qmake projects.
When it is not specified, the computed value is the lower case of the
CMake target name. E.g. for qt_internal_add_module(Core), the computed
CONFIG_MODULE_NAME is 'core'.
The qmake variable that determines the above value is the MODULE
variable.
If it is not explicitly assigned, it's computed from the .pro file
name, rather than from the TARGET variable value.
Thus there is an inconsistency in how the value is auto-computed in
CMake compared to qmake.
We had a few special cases in projects that assign a correct
CONFIG_MODULE_NAME when the auto-computed value was wrong.
Teach pro2cmake to detect these inconsistencies and pass a correct
CONFIG_MODULE_NAME value based on the .pro file name. This way
we get rid of the special cases as well.
Aka if there is no explicit MODULE assignment in the .pro file, and the
auto-computed value by CMake is different from the one computed by
qmake, explicitly write out a CONFIG_MODULE_NAME value with what qmake
would have computed.
Task-number: QTBUG-88025
Change-Id: I166b29767e87cd6b0c681fa53238098355a177f9
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Now that qt_add_executable doesn't set the WIN32_EXECUTABLE and
MACOSX_BUNDLE properties anymore, pro2cmake needs to look at the qmake
example projects and generate appropriate set_target_properties calls.
The relevant CONFIG entries to look at are windows, console,
app_bundle and cmdline.
CONFIG += windows implies 'subsystem windows' on Windows, which maps
to WIN32_EXECUTABLE == TRUE.
CONFIG += console implies 'subsystem console' on Windows, which maps
to WIN32_EXECUTABLE == FALSE. Aka the opposite of CONFIG += windows.
Whichever is the last one set, cancels out the other one.
CONFIG += app_bundle implies a macOS bundle executable, which maps
to MACOSX_BUNDLE == TRUE.
CONFIG += cmdline is the same as CONFIG += console and CONFIG -=
app_bundle, aka WIN32_EXECUTABLE and MACOSX_BUNDLE set to false.
In qmake, if no CONFIG is specified in an example project,
the default is CONFIG += windows app_bundle, aka WIN32_EXECUTABLE
and MACOSX_BUNDLE set to true.
The script uses a heuristic to try and not write the properties for
every single subscope, except for values different from the default.
This is not strictly correct, but it covers most use cases, and keeps
the generated projects a bit cleaner.
Task-number: QTBUG-87664
Task-number: QTBUG-86827
Change-Id: If05606ec3205e0fe7c1803c07e114d9fd9c3e4f7
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
The singleton modifier must be written without square brackets.
Task-number: QTBUG-87684
Change-Id: I924bbf97789edd7f2b4f2b9bbca2cb99841d2906
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Also adjust pro2cmake to use the new qt_add_executable name
instead of add_qt_gui_executable.
No compatibility functions provided this time, so we'll need to follow
through all repos and regenerate all examples.
Two reasons for not providing compaitibility functions:
1) We don't intend add_qt_gui_executable to be public API
2) A previous case with qtquickcontrols2 and qttools pointed out that
making top-level builds work with cross-compatibility API is not
simple. So just go ahead and regenerate everything.
Task-number: QTBUG-87661
Change-Id: I2f228827b786ae03bf7e1bf3908ea02a8794ed52
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
In order to funnel this through CMakeLists.txt we add an
OPTIONAL_IMPORTS entry in addition to the existing IMPORTS.
Task-number: QTBUG-87130
Change-Id: I57e882e75d17f5bc68d99ce7837425981fe6938b
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Offer compatibility wrapper functions until we update all of the Qt
repos to use the new names.
Task-number: QTBUG-86815
Change-Id: I5826a4116f52a8509db32601ef7c200f9bd331de
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
This adds the option to build Qt with libb2, which is especially
recommended, if you care about the performance of the BLAKE2 hashing
algorithms. The bundled version is the pure reference C implementation
of BLAKE2, while libb2 has many additional hardware optimizations.
However, the API of both is the same, so no changes to the code were
necessary here.
Change-Id: I3563982f4e07be300291fe103c38b16a404b3ebb
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Changes pro2cmake to handle load(qt_app) projects and write out
qt_internal_add_app calls.
Also adds handling of macOS and Windows specific resource files for Qt
apps only.
Task-number: QTBUG-85757
Change-Id: I994d8d19ab2ae366a985cab7894b97d6a278a56f
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
