Passing arguments with equal signs was broken for configure.bat and
qt-configure-module.bat. An argument FOO=BAR was split at = and written
as
FOO
BAR
to config.opt, breaking every attempt of assigning CMake variables.
We must not iterate over %* in batch files to avoid splitting arguments
at equal signs. Instead, pass %* unmodified to a CMake script that
writes config.opt.
Fixes: QTBUG-88019
Change-Id: I7c743a206961d1ed168f2313f864905f6b345b49
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
In a subsequent change we will call another CMake script from
qt-configure-module.bat. Write the location of qtbase/cmake into the
generated scripts instead of the path to QtProcessConfigureArgs.cmake.
Change-Id: Ie333b16d310b215c6e49efa27740c7525453d28f
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
CMake's --install --strip command will result in calling ${CMAKE_STRIP}
after installation.
On the build machines we have multiple compilers, and ${CMAKE_STRIP} will
have a valid program e.g. C:/strawberry/c/bin/strip.exe
This will change the MSVC binaries to have a MinGW linker version flag,
which confuses Qt Creator when setting up a MSVC Kit.
Amends 2044992eed
Fixes: QTBUG-87735
Change-Id: I1b3d4cc122b3f502810d48e0443f39824016cab5
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
This is meant to be called by our CI instructions to build standalone
tests of a Qt repository.
Currently it just calls qt-cmake with
-DQT_BUILD_STANDALONE_TESTS=ON, but it might contain more things in
the future.
The script also simplifies configuring standalone tests locally, due
to not having to remember the name of the magical variable.
Change our CI instructions to use the new script.
Change-Id: I6bc02b4e94adc9d0d05fecb0fe70a561043271f1
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
For QMake's -install argument it's necessary to have -qtconf in front.
Task-number: QTBUG-87801
Change-Id: I042acdd143972cc4065660035b02678db891157f
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
We're ensuring its existence right in the next line.
Change-Id: If7a55511c9ef839a9f9ae70a7928b58ad768ae65
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
We need to make sure to create a config.opt file, even if it's empty.
This is the same fix we did for the .bat file in
dad9550305.
Change-Id: I79c507cfe0f9517d3033a773d3a5cf69eb13cfe6
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Declaring and implementing out of line a specialization for
QESDP's destructor is needed if we have an implicitly shared
type and we want to provide an inline move constructor for it.
The code is however a bit heavy on the eyes, and the full
implementation for the destructor must be provided (read:
copy and pasted) -- the specialization destructor cannot
just "reuse" the one from the primary template.
This patch adds a few macros to streamline the above, so
that we can start using the same pattern in more places.
These macros are completely private for the moment being;
we don't want to push this solution for our users.
Port QPixmap to the new macros.
Change-Id: Ia6a51ad988483e44c9d97c0eca2fb003b6bd21e3
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
To avoid big artifact sizes, strip the binaries and libraries upon
installation. This achieves stripping similar to QTBUG-69767 and
QTBUG-81301 but arguably in a cleaner CMake way.
See comment on PS34 of the unmerged commit
90b09fee44b08b65a436fd15fda2526e242f7b21 for details.
Task-number: QTBUG-86053
Change-Id: I3ed929a8a7c74b88c480543212fc9551d8bde77f
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
We need to make sure to create a config.opt file, even if it's empty.
Change-Id: If1e41cea2f3b5f3ce67f30285b77c58f7376546a
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
Add a convenience script to configure a Qt module separately.
This script reads and interprets the qt_cmdline.cmake files of the
Qt module to be configured and eventually calls qt-cmake-private.
Example usage:
<install-prefix>/bin/qt-configure-module <source-root>/qtdeclarative
-qml-network -- --trace-expand --trace-redirect=cmake.trace
Change-Id: I026f1a050cd3f4df740611c32ba8c03161bba7a3
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
Normalize newlines so that headers on Windows are not
always treated as outdated.
This amends 108fb2f197.
Task-number: QTBUG-86121
Change-Id: I46ddb3c5b42852bff75fd56ca224c555ac0bae94
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
This makes sure the executable is run as a shell script
with the proper interpreter on Unix systems.
Otherwise it will fail in some shells, like fish.
On windows, it prevents all commands in the batch file
from displaying on the screen.
Change-Id: If554262f172b035b9661b3e2ff26a96789fa707b
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Previously syncqt did not write content to forwarding headers if they
already existed in the target location, regardless of the contents of
the forwarding header.
This is different from syncqt's behavior when it actually copies
the headers to the target location, instead of creating a forwarding
header that includes another header.
Fix syncqt to read existing forwarding header content, and update the
content in case if it's different from the newly generated content.
This should fix the following non-prefix build case: running syncqt
from a different source + build directory would not update the
forwarding headers in the qtbase build dir.
Change-Id: Ia0a1665a36ce54f1c487101d9a7532fc0aa40c89
Reviewed-by: Brett Stottlemyer <bstottle@ford.com>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
When cross-compiling, we now create a target_qt.conf file that's to be
used with the host Qt's qmake. With "qmake -qtconf .../target_qt.conf"
projects can be cross-built against the cross-built Qt.
We also create wrapper scripts for the host qmake to save the user from
passing the -qtconf argument.
Fixes: QTBUG-82581
Change-Id: Ib5866e7e820369efea9eb3171e3e3e3ca5c0c3c1
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Calling cmake --install . only installs a single configuration.
To install both debug and release artifacts, the install
invocation needs to be done for each configuration.
To keep the Coin instruction code simpler, delegate the looping
over configurations to a custom CMake script, and use it in the
Coin instructions.
Replace all cmake --install calls in the instructions with calls
to either call_host_install.yaml or call_target_install.yaml.
The path to the script depends on whether we are building
qtbase or another module. In the former case the script should
be called from the build dir, otherwise from the install dir.
The other distinction is whether the host or target env prefix
needs to be added.
Task-number: QTBUG-80900
Change-Id: Ied4bf739e2b1a2307f22fc79c1cfad746c8cbc44
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Aka handle CMAKE_INSTALL_PREFIX in a more relocatable way.
The following story inspired this change.
If a user wants to build a Qt repo into a different install prefix
than the usual Qt one, this will fail configuration because we
look for various things like syncqt, qdoc, etc relative to
CMAKE_INSTALL_PREFIX, which will now point to a different location
where none of the above tools are located.
The intent for such a use case is to support building Qt packages with
Conan, which sets a random install prefix when configuring a repo.
The idea is to derive the qt prefix dynamically from the
QtBuildInternals package location. Essentially it's a reverse relative
path from the QtBuildInternalsConfig.cmake file to the install prefix
that was specified when initially configuring qtbase.
Once the dynamic prefix is computed (so we know where the possibly
relocated Qt is), we can find tools like syncqt and qdoc.
This is an initial attempt to support a use case like that.
More design work will probably needed in case if tools / libs need to
be found in a location different than the Qt install prefix (so
support for multiple install prefixes / search paths).
An example of such a case would be when building qtdeclarative and
qtquickcontrols2 as Conan packages in one go. Most likely the
qmltyperegistrar tool will be located in the random install prefix
set by Conan, so building qtquickcontrols2 might fail due to not
finding the tool in the original Qt install prefix.
As to the implementation details, the change does the following:
- Dynamically computes and sets the
QT_BUILD_INTERNALS_RELOCATABLE_INSTALL_PREFIX variable when
find_package()'ing QtBuildInternals. It's an absolute path
pointing to where the relocated Qt is.
- When building qtbase this variable is not yet available (due
to QtBuildInternalsExtra not existing), in that case we set
the variable to the absolute path of CMAKE_INSTALL_PREFIX
(but only for the initial qtbase configuration).
- Remove QT_BUILD_INTERNALS_ORIGINAL_INSTALL_PREFIX which was used
for standalone tests purposes. It's not needed now that we compute
the location of the Qt prefix dynamically.
- The Unixy qt-cmake and qt-cmake-private shell scripts now
use a relative path to find the toolchain file we created.
- The toolchain file also dynamically computes the location of the Qt
packages, and adds them to CMAKE_PREFIX_PATH.
- A lot of existing CMAKE_INSTALL_PREFIX uses are replaced with
QT_BUILD_INTERNALS_RELOCATABLE_INSTALL_PREFIX. This includes finding
tool locations, mkspecs dir, path environment setup for tools, etc.
- Some places still use CMAKE_PREFIX_PATH in the following cases
- When determining paths while configuring qtbase (valid cases)
- When I wasn't sure what the behavior should be, so I left them
as-is (an example is documentation generation, do we want to
install it into the random Conan prefix, or into the main prefix?
Currently it installs in the random prefix).
Note that relocating a Qt installation does not work for non-prefix /
non-installed builds, due to hardcoded paths to include directories
and libraries in generated FooTargets.cmake files.
Task-number: QTBUG-83999
Change-Id: I87d6558729db93121b1715771034b03ce3295923
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Otherwise we will fail to resolve the symbol and will not create
a forwarding header for the class.
Change-Id: I34922d8458bdb994a194108183ac9b9d14530c5e
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Before this patch there were a few ways to build tests
- Configure all tests as part of the repo build
- Configure all tests as part of the repo build, but don't build
tests by default (-DQT_NO_MAKE_TESTS=ON)
- Configure all tests as a standalone project in a separate build
dir using -QT_BUILD_STANDALONE_TESTS=ON
All of the above incur some time overhead due to the necessity
of configuring all tests.
Sometimes you just want to build ONE test (or a few).
To facilitate that use case, a new shell script called
bin/qt-cmake-standalone-test(.bat) can now be used to configure
and build one or more tests.
The script takes one single argument pointing to the desired test
project path and configures a generic template project that sets up
all the necessary Qt CMake private API, afterwards calling
add_subdirectory on the passed in project.
Example
$ path/to/qt/bin/qt-cmake-standalone-test ./tests/auto/gui/image/qicon
or
$ path/to/qt/bin/qt-cmake-standalone-test ./tests/auto/gui/image
After that, simply run 'ninja && ctest' to build and run the test(s).
This is the CMake equivalent of calling qmake on a test .pro file
(or on a tests SUBDIRS .pro file)
There are 3 details worth mentioning.
Due to the add_subdirectory call, the built artifacts will not
be in the top-level build dir, but rather in a nested build_dir.
The script currently can't handle more than one argument
(the path to the project), so you can't pass additional
-DFoo=bar arguments.
If a test uses a 3rd party library (like Threads::Threads)
which was not a public dependency for any of the Qt modules,
configuration will fail saying that the target was not found.
Perhaps we should consider recording these packages when
generating the StandaloneConfig.cmake files.
Change-Id: Icde6ecb839341d34f341d9a19402c91196ed5aa0
Reviewed-by: Leander Beernaert <leander.beernaert@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
This allows doing debug_and_release builds with Ninja on all
platforms.
The "Ninja Multi-Config generator" is available starting with CMake
3.17.
Desired configurations can be set via CMAKE_CONFIGURATION_TYPES.
Possible values: "Release, Debug, RelWithDebInfo, MinRelSize".
For example -DCMAKE_CONFIGURATION_TYPES="Release;Debug".
The first configuration is the 'default' configuration which is
built when calling ninja with no arguments.
To build all targets of a certain configuration use "ninja all:Release"
or "ninja all:Debug".
To build all targets in all configurations use "ninja all:all".
Note that the first configuration influences which configuration of
tools will be used when building the libraries for all configurations.
In simple terms, when configured with
-DCMAKE_CONFIGURATION_TYPES="Release;Debug" the release version of moc
is used by AUTOMOC.
When configured with -DCMAKE_CONFIGURATION_TYPES="Debug;Release"
the debug version of moc is used by AUTOMOC.
Framework builds and Ninja Multi-Config don't currently work together
due to multiple bugs in CMake, which ends up generating an invalid ninja
file with duplicate rules. There are also issues with placement of the
debug artifacts.
This will be handled in a follow up patch after CMake is fixed.
Task-number: QTBUG-76899
Change-Id: If224adc0b71b7d1d6606738101536146aa866cd7
Reviewed-by: Qt CMake Build Bot
Reviewed-by: Leander Beernaert <leander.beernaert@qt.io>
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
Rather than tweaking the parser to cover every eventuality with corner
case lines that could cause incorrect header files to be created then
the means to suspend/resume the processing of a file is added.
This enables us to have it skip over the template line that is causing
a QList header to be created as part of the QtGui headers. This patch
includes the fix to solve this in addition.
Fixes: QTBUG-68129
Change-Id: I751646c4b20a4434347c149ae5e6dcb6e7618853
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
This broke when QLatin1Literal got deprecated in change 45373c1924
Both hunks in this patch are needed. The hunk in syncqt.pl removes the
QT_DEPRECATED_X(...) macro if it appears solely on a line in source code,
the second hunk inserts a newline after the QT_DEPRECATED_X(...) macro usage
to trigger that code path in the Perl script.
Before/after comparison of the headers generated in include/QtCore:
```
% diff ~/old.txt ~/new.txt
105a106
> QLatin1Literal
```
Change-Id: I468dd2dd54bf115521ed82c6182236905556f568
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
In Windows-msys syncqt.pl expects CRLF line endings, and does not
work correctly with LF. syncqt.pl was fixed to be line-ending-agnostic.
Task-number: QTBUG-77192
Change-Id: Ie8029238bdd580bcf042ede0d0f64d5f01488406
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
Modified a regular expression in syncqt.pl so that the special case of
a class beginning with another class does not lead to the exclusion of
the first one. This affects the generation of the install target for
generated class headers of Qt modules. Now the expression verifies the
class names are not identical.
Fixes: QTBUG-71323
Change-Id: I210b4d4c3ed64cf189594b95b10aa0e8495a19d2
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
Previously the cmake install prefix was added twice during a non-prefix
build, which evaluated to an incorrect path.
Set another absolute dir variable, and use that instead.
Change-Id: I73099510dadc8f401d5a763f21840c9671686c10
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Reviewed-by: Qt CMake Build Bot
Similar to the shell script, this makes it easier to invoke cmake by
just extending your PATH.
Change-Id: I1f83e93c507032f6ecf4838c11d62f49f4d93ed6
Reviewed-by: Qt CMake Build Bot
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
This gets us a step into the direction of convenience that qmake
offered:
* QtBase is configured with a long command line (especially when
cross-compiling)
* Afterwards application developers (or other module builds) can
just use qmake && make
By generating a toolchain file we can capture vcpkg and toolchain
chain-loading and a shell script can take care of providing the prefix
path.
Change-Id: Ided81f5432cab862306f2bea86cfe8e56adf71b0
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Injected headers were made relative to MODULE_BASE_OUTDIR by syncqt
and made absolute by resolving against REAL_MODULE_BASE_OUTDIR.
This breaks for modules that reside outside the original Qt source
tree (if the directory depth doesn't coincidentally match).
Now, we resolve injected headers against build_basedir, which is
REAL_MODULE_BASE_OUTDIR. To emphasize the equivalence of
REAL_MODULE_BASE_OUTDIR and syncqt's build_basedir, use the former for
syncqt's -output argument.
This commit amends 2aa779e8.
Fixes: QTBUG-70587
Change-Id: I2935d87d7ee681fa4aa795a270b94ab7a43abe59
Reviewed-by: Dominik Holland <dominik.holland@pelagicore.com>
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
It is possible that "syncqt -minimal" is run after a module's initial run
(for example if a host tool relies on a module, but cannot use it
directly and thus adds minimal_syncqt to its .pro file). In this case, the
old directory content should not be wiped.
Fixes: QTBUG-59319
Change-Id: I83767eff0ef74bcefae5efa9b18b7ab3724138e5
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
in non-prefix builds, the forwarding headers always end up in qtbase's
build dir, while the injected headers always live in the build dir of
the module they belong to. to deal with that, we now record the target
path relative to the module root dir instead of relative to the base
directory of the forwarding header itself.
Fixes: QTBUG-70056
Change-Id: Ic4346148a125b13e2610f6965cdf4f5266ac763e
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
following the same mechanism as qpa headers, one can specify a list of
regexes in the @private_headers variable in sync.profile.
Change-Id: I5de0284e639ad283561f54dba7dda8c6437b23f8
Reviewed-by: Johan Helsing <johan.helsing@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
this variable hasn't been used in any syncqt.profile for many years, and
if it would, it would cause quite some side effects.
Change-Id: Ia936eff8f6a2a801fc644eee991821165d51dc1f
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
don't put them into GENERATED_HEADER_FILES, as they obviously cannot be
found in a pre-synced source dir. instead, let the injection code itself
add them to INJECTED_HEADER_FILES.
Task-number: QTBUG-67813
Change-Id: Id2a7c565b14fcba8aba9d1dd8b1dd39c586d0d91
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
these are actually redundant with INJECTIONS.
Change-Id: I0a71930401e00d30c9898b4d958de5e89c496d18
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
instead of relying on more or less accidental qmake behaviors regarding
the base dir for relative paths (esp. if a file does not exist yet),
make everything explicit. to that effect, clearly define the base tree
(source or build) for every syncqt-generated variable, and write only
in-tree relative paths to the variables. on the receiving end, resolve
the paths as soon as headers.pri was read.
Task-number: QTBUG-67111
Change-Id: I32ae5760fb62ebc650fdb69e46aac786a8141564
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
creating private deprecated forwarding headers is rather pointless, as
keeping source compatibility for private headers is unnecessary.
consequently, the feature wasn't used anywhere. remove it to reduce
complexity.
Change-Id: I6202e5141f0387615f90efa0ec707ac208419227
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
it's been a no-op (always on anyway) for quite some time now.
Change-Id: I9611ca73ddaef4422a16d85338e1dae473a50fbf
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
that parameter is never set, and if it was, it wouldn't work: the
recursively found files were not qualified with the subdirectory.
Change-Id: I24a3f74de3545c19bcd175c24ad1daf2af77a720
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
it needs to fall back to -outdir if only the latter is specified, as
otherwise funny things will happen.
this didn't affect the calls in qt_module_headers.prf (both options
used) and the unix configure script (neither option used), but it
affected configure.bat, and possible callers outside qt's build system,
which apparently includes our packaging scripts.
amends ede6c44756.
Task-number: QTBUG-66626
Change-Id: I08633033c04152616545501490c9b3fb939cab6c
Reviewed-by: Lionel CHAZALLON <longchair@hotmail.com>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
in non-prefix configs, one has to differentiate between the module's own
build dir and qtbase's build dir, because the forwarding headers are
placed in -outdir under include/, while the actual headers end up in the
real build dir under src/.
Change-Id: I1d8ac904556b354bd113995316ba11dd6560a70d
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
don't pass arguments, as the sourced sync.profile's make assumptions
about the global variables' presence anyway.
don't return a value, as it's ignored anyway.
fix the documentation (also that of locateSyncProfile()).
Change-Id: I7527546718b12737d7a4551a834d7f0ca26a8a7e
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
