02.10.2020, 16:20, "Konstantin Tokarev" <annu...@yandex.ru>: > 02.10.2020, 15:53, "Toni Saario" <toni.saa...@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 _______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
