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>
