After this change, private CMake scripts are mostly live in
`libexec/`, except the `qt-cmake` which will stay in `bin/`.
This doesn't affect the Windows configuration.
- `qt-cmake` stays in `bin/`
- `qt-configure-module` moves into `libexec/`
- `qt-cmake-private` moves into `libexec/`
- `qt-cmake-private-install.cmake` moves into `libexec/`
- `qt-cmake-standalone-test` moves into `libexec/`
- `qt-internal-configure-test` moves into `libexec/`
In cases where `QT_GENERATE_WRAPPER_SCRIPTS_FOR_ALL_HOSTS` is set to
ON, e.g., ANDROID, WASM, both Batch and Bash files will be generated
and placed in `bin/` and `libexec/` accordingly; in both cases,
qt-cmake and qt-cmake.bat will be in `bin/` anyway.
[ChangeLog][CMake] The private Qt CMake scripts, i.e.,
qt-configure-module, qt-cmake-private, qt-cmake-private-install.cmake,
qt-cmake-standalone-test and qt-internal-configure-test were moved
into $prefix/libexec on Unix platforms.
Fixes: QTBUG-107621
Change-Id: Ic4f4ec85f64d2ede0e208bca928959e30be906a6
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Cross-builds already were out-of-source.
Move non-cross-builds to out-of-source as well.
Fixes: QTBUG-82820
Fixes: QTBUG-96513
Change-Id: I5bef08f18a16e51fe2c501565699494b46546f84
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
We want to use configure and qt-configure-module when building in
Coin, rather than pure cmake and qt-cmake.
There are a few benefits:
- CI tests the scripts, making sure we don't introduce regressions
- CI uses the same scripts that we mention in our documentation for
developers to use
- The platform configurations become a bit less verbose and easier to
read due to less shouty-case CMake options
To ensure a more gradual porting, Coin will only use the new
instructions if the 'UseConfigure' feature is set on a platform
configuration in qt5.git. This allows going back to the old
instructions in case if something isn't working properly.
Due the opt-in, we need to support both old and new instructions in
the implementation.
The change strives to remove as much duplicate code as possible,
by moving it into common includes.
The README.md is updated to mention the overview of how the different
environment variables are used.
There are a few important things to point out.
1) Because during the porting we have to allow mixing of the old style
and new style, platform configs have to separate CMake-style options
from configure-style options in different environment variables.
Otherwise the instructions wouldn't be able to create a valid
configure call, where all CMake-style options have to go at the end
after a double dash --.
After all platform configs are ported to the new style, it should be
possible to combine all the options in a single environment variable
if that is desired, but it will require another round of porting to
remove all the '-D' prefixes in CMake-style options, and just use
regular variable assignment which configure supports.
e.g. -DQT_BUILD_EXAMPLES=ON becomes QT_BUILD_EXAMPLES=ON, which can be
mixed in-between configure-style args.
2) Configure is more strict in that it doesn't allow passing
unknown options. Due to that, we can't pass non-qtbase configure
options via NON_QTBASE_CONFIGURE_ARGS. qt-configure-module would
error out in the repos where the configure option is unknown.
Because we don't have a Coin configure variable for each repo,
we circumvent the issue by continuing to pass CMake-style options via
NON_QTBASE_CMAKE_ARGS instead, which does not do validation checks.
In the future, we could introduce a configure flag that disables
the validation checks.
Pick-to: 6.2 6.3
Task-number: QTQAINFRA-4357
Task-number: QTQAINFRA-4815
Change-Id: I72d8ba0b3a543b42982e22ae8d6566c0e885c446
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Toni Saario <toni.saario@qt.io>
This part originates from when the CMake was being introduced and
now things are stable enough that the bug rarely is everywhere.
Pick-to: 6.2 6.3
Task-number: COIN-828
Change-Id: Ifb7b5ce82740f5ae49f712f9666870993ce00b15
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
As a drive-by this fixes the qtbase build to also have the
CMAKE_AUTOGEN_VERBOSE option set.
Pick-to: 6.2 6.3
Change-Id: I32324fb1e8e16299c5f34517edbc7ff335d84e14
Reviewed-by: Toni Saario <toni.saario@qt.io>
We want to remove the Qt .pro files for projects, except examples,
because examples are still meant to build with qmake.
To not lose coverage on examples built with qmake, add instructions that
will build the qtrepo/examples folder with qmake when the CMake
configuration has -DQT_BUILD_EXAMPLES=ON.
This means that such configurations will build examples both with CMake
and qmake.
Aside from making sure that our examples will still build with qmake, it
will gives us some some coverage that a CMake-built qmake works
correctly.
Implementation-wise, add new instructions files that can call qmake and
make depending on configuration and target type.
Pick-to: 6.0
Fixes: QTBUG-85986
Change-Id: Ie8f4cbcda03c94da2aef455e32f48dad41a4bdb0
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
For consistency, apply the following renamings:
QT_NO_MAKE_EXAMPLES -> QT_BUILD_EXAMPLES_BY_DEFAULT
QT_NO_MAKE_TESTS -> QT_BUILD_TESTS_BY_DEFAULT
QT_NO_MAKE_TOOLS -> QT_BUILD_TOOLS_BY_DEFAULT
BUILD_EXAMPLES -> QT_BUILD_EXAMPLES
BUILD_TESTING -> QT_BUILD_TESTS
This should help to better convey the difference between "BUILD" and
"NO_MAKE".
To configure tests, but not to build them by default, pass the
following to CMake:
-DQT_BUILD_TESTS=ON -DQT_BUILD_TESTS_BY_DEFAULT=OFF
Analoguous for examples:
-DQT_BUILD_EXAMPLES=ON -DQT_BUILD_EXAMPLES_BY_DEFAULT=OFF
Tools can be excluded from the default build with:
-DBUILD_TOOLS_BY_DEFAULT=OFF
The variable BUILD_TESTING is still available and initialized with the
value of QT_BUILD_TESTS.
Pick-to: 6.0 6.0.0
Change-Id: Ie5f29dfbdca8bfa8d687981dfe8c19c0397ca080
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>
To allow seeing the exact compiler flags when build in Coin.
We do the same for qmake builds.
Change-Id: I8c43f35b95d722d914aaeaa8860720a3a0578737
Reviewed-by: Leander Beernaert <leander.beernaert@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Change-Id: Id274bf821f424077e7259ed42433f2ef88153c36
Reviewed-by: Toni Saario <toni.saario@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Change-Id: I3906a08f5e0cce9abeeafbb67a83d31fbf67c703
Reviewed-by: Toni Saario <toni.saario@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
