The value of the 'qt_host_path' option needs to be resolved fully
before assigning it to 'QT_HOST_PATH' env.
This icludes expanding ~ constructs, resolving symlinks, expanding vars
and relative paths.
Pick-to: 6.2 6.3 6.3.0
Change-Id: Ia338105ccb4a203796864304f463b222163c5193
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
This got broken in: 58c6f37ed06c9cbc4de2ce8c87a9608bd628c64d
Fix it to use the correct function from qt-conan-common.
Pick-to: 6.3 6.3.0 6.2
Change-Id: Ia381672d17ce5bd33e0a9aded3b7125ebb0bcb6e
Reviewed-by: Toni Saario <toni.saario@qt.io>
Fix indentation of a function declaration.
Pick-to: 6.3 6.3.0
Change-Id: Ib2aed12f2549e4b0ee5ee21a59c2c7b9db726a7e
Reviewed-by: Toni Saario <toni.saario@qt.io>
The Android specific option values need to be included in the
'package_id' to avoid mixing Android binaries built with
different Android sdk, ndk, abis etc.
The 'android_ndk' path can not be used as the option value as such
because this is a local file system path that may be different
on each system. This would make the pre-built binaries unusable
as the value is part of the 'package_id' checksum.
Instead, parse the 'Pkg.Revision' from the 'source.properties'
file pointed by the original 'android_ndk' option value and
use this as the 'android_ndk' option value for the 'package_id'.
The 'QT_ANDROID_API_VERSION' can be used for 'android_sdk' value
for package_id if passed as cmake argument. If not then
currently we need to remove the 'android_sdk' from package_id
calculation as we don't have clear means to query that from
the build system. This should hopefully be fixed in future
releases.
Pick-to: 6.2 6.3
Task-number: QTQAINFRA-4646
Change-Id: I679fbdcf92a1d93e00685215bb011948f1aba71f
Reviewed-by: Toni Saario <toni.saario@qt.io>
Common module uses the qt-cmake-private-install to install.
This ensures all configurations are installed.
Pick-to: 6.2
Change-Id: I4be97685c25392838dbc7ab7c3526f55987c08e6
Reviewed-by: Iikka Eklund <iikka.eklund@qt.io>
The option name should be passed instead of it's value.
Pick-to: 6.2 6.3
Change-Id: I74529c36c438f5d40ecd4dcf689b3ea2a100e5fb
Reviewed-by: Iikka Eklund <iikka.eklund@qt.io>
To make the Qt conan package consumption more seamless for consumers
who use e.g. conan-center packages we should try to make sure that
"the default conan build profiles" people are using should work
with Qt conan packages as well.
This means that we should support the use case that when consumers
are not explicitly defining Qt specific build options, e.g.
-o debug_and_release=True
And the consumer build profiles/settings may contain e.g.
[settings]
...
build_type=RelWithDebInfo
In qtbase conan recipe this should translate to correct
'Options' specific to Qt's configure(.bat).
This change introduces a fallback in case Qt specific
options are not being passed. It sets the Qt specific
options based on the settings.build_type.
Pick-to: 6.2 6.3
Task-number: QTBUG-99571
Change-Id: I961570a100fadc03b8c423dcf0064ccc4be7ae6e
Reviewed-by: Toni Saario <toni.saario@qt.io>
The recipes in conan-center use True/False option values for common
binary options, for example:
- shared
- release
Currently the binary option values for Qt recipes use 'yes'/'no' values
which makes the consumption of Qt conan packages suboptimal.
Example:
$ conan install .. -o qtbase:shared=yes -o shared=True
After the change one can use:
$ conan install .. -o shared=True
The shared=True is applied to all packages in the dependency tree
including Qt now.
Adjust how the booleaness is checked for Conan options which are
wrapped with PackageOptionValue.
Pick-to: 6.2 6.3
Task-number: QTBUG-99558
Change-Id: I52e16d76418ac3c3e9d653e77287ae89248675d7
Reviewed-by: Toni Saario <toni.saario@qt.io>
If the "icu" option is passed for the build then add the optional
ICU Conan package dependency. The ICU version needs to be parsed
from a file which is provisioned by the Qt CI.
If the ICU version can not be parsed, e.g. if "conan export" is
being executed outside Qt CI machines, then use a fallback
version for it.
For the Qt build system to pick up the ICU dependency built
by Conan we need to pass the ICU package path via
CMAKE_PREFIX_PATH.
Pick-to: 6.2 6.3
Task-number: QTBUG-97072
Change-Id: I83059664c59dff68af76da8509e618442b530516
Reviewed-by: Toni Saario <toni.saario@qt.io>
The 'qt_host_path' should not affect the package_id as it is most
probably completely different in different environment and would make
the CI produced cross compiled binaries unusable by end users.
Pick-to: 6.2 6.3
Change-Id: I91019dacb99a3ee69fadbf3435d37bac0c279330
Reviewed-by: Toni Saario <toni.saario@qt.io>
it avoids global conan configuration in conan.conf
or via environment variables
Pick-to: 6.2
Change-Id: Ia54cbfe95e0864e7107ea3bb53ff9ba4f1df7b60
Reviewed-by: Iikka Eklund <iikka.eklund@qt.io>
The qt.conf causes issues with CI and building/running tests.
Pick-to: 6.2
Task-number: QTBUG-93037
Change-Id: I079e71e64985eb69c37adaacb93c45a4a92ef4fa
Reviewed-by: Toni Saario <toni.saario@qt.io>
Currently e.g. -debug-and-release builds are "broken" as it only
produces release binaries on Windows. There are other inconsistencies
also how the recipe deals with various release and debug related options
and how those map the Conan's 'build_type'.
Pick-to: 6.2 6.2.1
Change-Id: I47fa4c1592eefa1b5a1f144691ee33675753e5fb
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
The package_revision_mode() is too strict for Qt CI.
This mode includes artifacts checksum in package_id which is
problematic in Qt CI re-runs (re-run flaky build) which contain
different build timestamps (cmake) which end up in library
files -> different package_id.
The effect was that Conan/Conan server is unable to re-use correct
binaries and re-builds (re-staged) dependencies.
Pick-to: 6.2 6.2.1
Change-Id: Id54af7455b948c8d68b7206d524f1d0fcfb7b568
Reviewed-by: Toni Saario <toni.saario@qt.io>
Conan supports Python3.5 which does not support f-strings yet.
Pick-to: 6.2
Change-Id: Ie4b64e3baff7da64b80db71f4f0ea4172ddc61fb
Reviewed-by: Toni Saario <toni.saario@qt.io>
By default Conan uses 'minor_mode' policy for 'python_requires'
dependencies. This causes updates in 'qt-conan-common' package not to
land into users when invoking e.g. "$conan instal .. --update".
Fix this by enforcing recipe revision mode so any changes to
'qt-conan-common' recipe is received by the clients when updating
packages.
Pick-to: 6.2
Change-Id: I225965aa76c39552bd4adc93d7e68e0ae0b38d56
Reviewed-by: Toni Saario <toni.saario@qt.io>
The android specific options were plain wrong:
- android_sdk_path -> android_sdk
- android_ndk_path -> android_ndk
These reflect the Qt configure options.
Pick-to: 6.2
Change-Id: I0b9283b6603aff8243208216baffe263d37b6541
Reviewed-by: Matti Paaso <matti.paaso@qt.io>
This option should not affect the binary compatibility thus it should
not be part of the package_id of the created Conan package.
Pick-to: 6.2
Change-Id: I6d09cc3933cd28c306ef011bb26346a0993ffcd3
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
The qtbase Conan recipe has 'cmake_args_qtbase" option to pass cmake
arguments. Some of the cmake arguments should not be included in the
package_id checksum of the Conan package. Filter these out when
generating the package_id.
Examples:
- -DCMAKE_C_COMPILER_LAUNCHER=sccache
- -DCMAKE_CXX_COMPILER_LAUNCHER=sccache
- -DFEATURE_headersclean=..
- -DPostgreSQL_ROOT=..
Those arguments which are specific to Qt CI build environment are
filtered out. This makes the pre-built Conan binary packages more
usable for the end users because Conan would enforce a build
from sources if the checksum(s) would not match.
Pick-to: 6.2
Task-number: QTBUG-96230
Change-Id: I076a57427614fdf4bf9138402e247d63f1ce15d9
Reviewed-by: Toni Saario <toni.saario@qt.io>
It turns out that we need to support two ways to pass cmake args as
Conan options. Those that are meant for qtbase only,
like "-DCMAKE_TOOLCHAIN_FILE={{.Env.ANDROID_NDK_ROOT}}", and those
that are meant for leaf modules only.
Rename the current 'extra_cmake_args' Conan recipe option as
'cmake_args_qtbase' to make it clear these cmake args are passed
to qtbase build only.
The leaf modules will be using 'cmake_args_leaf_module' as the
Conan option name.
Pick-to: 6.2
Change-Id: I456b8b07da5684f386cac668a5cd3e2509c733ac
Reviewed-by: Toni Saario <toni.saario@qt.io>
The qt-conan-common package contains shared functionality
for recipes that should be used:
- environment wrap during the build()
- package_info() is generic for all recipes
Move the _build() out from the class so that it is usable for
the callback from qt-conan-common package.
Simplify how the Qt module version and prerelease tag is
read from .cmake.conf and how the file is being referenced.
As the .cmake.conf is included in the "exports" it will
be always present next to the recipe:
- in .git source tree
- in Conan cache
Pick-to: 6.2
Change-Id: I4bbd683f7b49151620397e0b7f4272929a93c060
Reviewed-by: Toni Saario <toni.saario@qt.io>
The status information (alpha1, beta2, rc3, ...) needs to be part of
the Conan package reference.
As Conan supports semantic versioning the best place to put the status
is to append it to the version string:
qtbase/6.2.0-alpha1@qt/everywhere
qtbase/6.2.0-beta2@qt/everywhere
qtbase/6.2.0-rc3@qt/everywhere
qtbase/6.2.0@qt/everywhere
Other Conan packages declaring a dependency can use e.g. syntax:
# notice the asterix character after version
self.requires(f"qtbase/[<=<version>, include_prerelease=True}]@..)
This way the status information is not in the Conan channel part and
downstream consumers of the Conan package does not need to update
the dependency (Conan reference string) every time the version changes.
Put the status information next to Qt version string in .cmake.cache.
Task-number: QTBUG-94385
Pick-to: 6.2
Change-Id: Ib277f99ea1e87253b93f59e463bd6c7dd8b3203e
Reviewed-by: Toni Saario <toni.saario@qt.io>
Initial version of the conanfile.py to support builds with Conan
package manager. Tested with Linux, macOS and Windows desktop
builds first.
Use 'scm' revision_mode so that the revision matches with the git
commit id.
The recipe uses Qt's configure(.bat) and cmake directly,
'conans.CMake' utility tool is not used.
Load options dynamically based on configure(.bat) features:
- configure(.bat) -write-options-for-conan <output file>
- Expose all usable configure(.bat) options as Conan options
- We want to query configure(.bat) for available options and
features to avoid duplicating these in multiple places
- The available configure(.bat) option names are formatted to
suit as dictionary keys in Conan 'options'
The recipe writes 'configure_options.json' and
'configure_features.txt' which are exported as part of the
conan package. This is done only once during the 'conan export'
i.e. when the initial Conan package is being created.
The recipe will reference these files in later phases when needed.
The recipe translates the Qt configure options and features as
Conan options and default_options. When the build is invoked
('conan install') the recipe translates the Conan options back
to suitable Qt configure options which are then passed to
configure(.bat).
Additional cmake flags can be passed via 'extra_cmake_args' option:
$conan install ... -o extra_cmake_args="-DFOO=bar -DFOO2=bar2"
Remove those options from 'package_id' that point to local environment
like installation paths. These are most probably different on end user
machines making it impossible to re-use the pre-built binaries by Qt CI
as the path values would become of the 'package_id' checksum.
Task-number: QTBUG-92031
Change-Id: I4e47d116fdef6a5daa23aba22bac2b2d74d12c6e
Reviewed-by: Toni Saario <toni.saario@qt.io>
