[Development] Building additional components with Conan for Qt 6
Konstantin Tokarev
annulen at yandex.ru
Wed Oct 7 17:44:02 CEST 2020
02.10.2020, 16:20, "Konstantin Tokarev" <annulen at yandex.ru>:
> 02.10.2020, 15:53, "Toni Saario" <toni.saario at qt.io>:
>> One thing to check is that how much the provisioning it is possible to translate to Conan, I would believe that in the end it does not work for everything.
>
> Most of provisioning scripts fall into 2 categories:
> 1) Download installer (or other binary package) of 3rd party stuff, verify checksum, install. These scripts are quite simple.
> 2) Build stuff from sources in provisioning time, sometimes in a sophisticated way (e.g. https://code.qt.io/cgit/qt/qt5.git/tree/coin/provisioning/common/windows/android-openssl.ps1). These can be (and IMO should be) replaced with Conan, to reduce provisioning time and complexity.
Of course, it's also possible to use conan packages for category (1), however this may require writing quite a few custom recipes (see manual [1]), possibly containing more boilerplate than existing ps1 snippets. However, this would allow to have a nice list of all provisioned packages with their versions in one place.
[1] https://docs.conan.io/en/latest/devtools/create_installer_packages.html#create-installer-packages
>> As for provisioning and why the CI images are different from what are documented, biggest problem there is that the images are used by other components also e.g. RTA testing. Those require some additional stuff and provisioning currently installs everything. AFAIK also all the optional dependencies are installed, this makes it hard to distinguish between them and required dependencies because both are always present. These make it easy that new dependencies etc. slip through unnoticed.
>
> Note that when Conan packages are used via conanfiles (i.e. as it's originally intended by Conan developers), there cannot be any dependency slips because Conan dependencies don't become visible to any project which doesn't require them via conanfile (directly or indirectly).
In this case each testing activity should have its own conanfile with a list of dependencies, as well as each Qt project which uses them for building.
>
> I can see another possible way to use Conan in CI - install packages into the system via "deploy" generator so that Qt build system can find them without any knowledge of Conan. I guess this way may be called "Ossi-friendly because Ossi was adamantly opposed to any explicit support of Conan in build system, see e.g. https://codereview.qt-project.org/c/qt/qtbase/+/184241, however this way indeed may cause dependency slips.
--
Regards,
Konstantin
More information about the Development
mailing list