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>
Certain resources and compiled jar files have to be copied into the
non-prefix build dir location. They were previously only installed,
which doesn't do anything in a non-prefix build.
Change pro2cmake to generate code that places the compiled java
jars into QT_BUILD_DIR, so that non-prefix builds work.
Place the module dependencies xml files into lib folder in non-prefix
builds.
Don't special case the output and install location of the Android QPA
plugin.
Task-number: QTBUG-85399
Change-Id: I4ac9d3929ea8ecc95ec99a77e621ad2121b68832
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
qtdeclarative as of 41864db3b61d9e81a9fe4906918d2cd3d6d32a0c always
retains the resources, so there's no manual facility for retaining
left. Remove the code.
Change-Id: If79b66683897b5f430844e13c0230e41a2cf061d
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
If a file was part of a resource that has a non-empty base directory,
the script generated set_source_files_properties calls to the file
path without including the base dir, which means the command did
nothing.
The script should set the QT_SKIP_QUICKCOMPILER on the full file path
if a base dir is present, similar to how the alias handled.
Refactor the alias property writing code to write all properties
into the command that uses the full correct path.
Change-Id: Ic75d51ecf60eef3ada9bd6ca26882de3447896e9
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
You can write the following in a qmldir file these days:
import QtQuick auto
import QtQml 2.4
pro2cmake should understand and convert these to cmake.
Change-Id: Ica1728de0c8d7a0b2b5aa341d20e60b23dfa7fe1
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
This patch allows tools to be built for the target platform when the
QT_BUILD_TOOLS_WHEN_CROSSCOMPILING parameter is set at configuration
time.
To avoid naming conflicts, the target tools are suffixed with "_native".
The qt_get_tool_target_name() function can be used to get the tool name
for both scenarios (cross and non-cross compilation).
Extend pro2cmake to refer to the right target name for tools.
The relevant write_XXX functions have a new target_ref parameter that
will be "${target_name}" for tools and literally the target name for
everything else.
Fixes: QTBUG-81901
Change-Id: If4efbc1fae07a4a3a044dd09c9c06be6d517825e
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
When writing the qt6_qml_type_registration call, make sure to write
the set(QT_QML_MODULE_INSTALL_QMLTYPES TRUE) statement only if an
explicit path was provided via
QMLTYPES_INSTALL_DIR / QT_QML_MODULE_INSTALL_DIR.
This will remove the QT_QML_MODULE_INSTALL_QMLTYPES property from
many examples and tests in qtdeclarative, thus not installing the
.qmltypes file into the Qt prefix, thus polluting it.
Task-number: QTBUG-84403
Change-Id: I5c64d42915896d14f2591cbb64d73d912dbf7c7d
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
For modules that are not yet ported to CMake and that use
QMAKE_USE += libfoo
we need to provide the information about libfoo in the qt_lib_XXX.pri
files.
Also, we now generate qt_ext_XXX.pri files for bundled 3rdparty libs.
Task-number: QTBUG-75666
Change-Id: I9e4b057a197554ecb37c294c0bf09e2a2b3aa053
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
QMake variables are always string lists, but some variables are used to
represent single string values. People tend to fill those variables with
multiple values and expect them to be joined by spaces.
Exhibit A: qtdeclarative/tools/qml/qml.pro
QMAKE_TARGET_DESCRIPTION = QML Runtime
QMake supports this for many values. Do the same for Scope.get_string().
Change-Id: I6af22bc1bfed07a4d8eac94d7315051a5bcb7a4d
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
We should search for the values of function names rather than
the mapping key.
Change-Id: Iedef7fcf4d716ff7f6d277d9626d9dc2dd781401
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
