QtCS2021 - Qt Conan packages: Difference between revisions
(Created page with "==Session Summary== The plan to provide Conan packages for Qt6 modules. Discussion about the current state where we are and where we aim for. ==Session owners== * Iikka Ekl...") |
No edit summary |
||
| (3 intermediate revisions by one other user not shown) | |||
| Line 1: | Line 1: | ||
[[Category:QtCS2021]] | |||
==Session Summary== | ==Session Summary== | ||
| Line 5: | Line 7: | ||
==Session owners== | ==Session owners== | ||
* Iikka Eklund (iikka.eklund@qt.io) | *Iikka Eklund (iikka.eklund@qt.io) | ||
* Toni Saario (toni.saario@qt.io) | *Toni Saario (toni.saario@qt.io) | ||
* Tino Pyssysalo (tino.pyssysalo@qt.io) | *Tino Pyssysalo (tino.pyssysalo@qt.io) | ||
==Notes== | ==Notes== | ||
Q: The Qt Company postponed the conan approach because we decided that we hadn't reached a state where it makes sense to use it. From the presentation it looks like usage is basically the same as before. Probably just not obvious on first glance, but what has improved since we decided to postpone? | |||
Back when I tried the Conan approach, everything looked quite complicated and it looks like it still is. | |||
A: in Qt 6.0, we had source only distribution for Qt additional libraries. Mixing two worlds: Qt Installer + Conan was not a good solution. User needed to install Qt Essentials first and then use Conan to install some sources. The benefit was seen, if Conan is really used everywhere. At the moment, Qt Base has Conan recipes and the goal is to have recipes for whole Qt by Qt 6.2 It makes more sense to build/install anything in Qt with Conan. | |||
Q: How do we want to roll out Conan? How it affects ordinary Qt developers? | |||
A: At the beginning, there will be a command line interface, which does not provide the same convenience as the installer. The goal is to provide a GUI frontend for Conan package management as well. We plan to test and collect usage experience feedback in 6.2 and improve the experience accordingly. Test packages should be available for Qt 6.2 | |||
The same applies to Qt Creator. We will investigate further, what features developers would need most. At the moment Qt Creator supports running conan --install and we will study how to specify/edit Conan profiles, for example. Also using Conan generators for creating qmake .pro files or CMake cmakelisttext files is supported. | |||
Q: Is it possible to export several modules into one base directory? | |||
Yes, it is possible with the --install <directory> command line option, though not recommended, as the basic feature of Conan is to keep the generated files in Conan cache rather than in some user-specified folder. Conan makes it easy as all versioned binaries with required profiles locate in the same cache folder. Possible to define dependencies per project, per recipe, per package. | |||
Q: Does deployment work with Conan? | |||
A: Not yet. macDeployQt should work out of the box, as it can take packages from any path. winDeployQt requires further investigation, but should not be too complicated there either. | |||
Q: What about the missing parallelism in Conan? | |||
A: Lots of discussion in Conan GitHub, plenty of options given by the community. At the moment, work is focused to Conan 2, after which parallel compression/decompression could be considered. No commitment yet. | |||
Latest revision as of 12:32, 23 June 2021
Session Summary
The plan to provide Conan packages for Qt6 modules. Discussion about the current state where we are and where we aim for.
Session owners
- Iikka Eklund (iikka.eklund@qt.io)
- Toni Saario (toni.saario@qt.io)
- Tino Pyssysalo (tino.pyssysalo@qt.io)
Notes
Q: The Qt Company postponed the conan approach because we decided that we hadn't reached a state where it makes sense to use it. From the presentation it looks like usage is basically the same as before. Probably just not obvious on first glance, but what has improved since we decided to postpone?
Back when I tried the Conan approach, everything looked quite complicated and it looks like it still is.
A: in Qt 6.0, we had source only distribution for Qt additional libraries. Mixing two worlds: Qt Installer + Conan was not a good solution. User needed to install Qt Essentials first and then use Conan to install some sources. The benefit was seen, if Conan is really used everywhere. At the moment, Qt Base has Conan recipes and the goal is to have recipes for whole Qt by Qt 6.2 It makes more sense to build/install anything in Qt with Conan.
Q: How do we want to roll out Conan? How it affects ordinary Qt developers?
A: At the beginning, there will be a command line interface, which does not provide the same convenience as the installer. The goal is to provide a GUI frontend for Conan package management as well. We plan to test and collect usage experience feedback in 6.2 and improve the experience accordingly. Test packages should be available for Qt 6.2
The same applies to Qt Creator. We will investigate further, what features developers would need most. At the moment Qt Creator supports running conan --install and we will study how to specify/edit Conan profiles, for example. Also using Conan generators for creating qmake .pro files or CMake cmakelisttext files is supported.
Q: Is it possible to export several modules into one base directory?
Yes, it is possible with the --install <directory> command line option, though not recommended, as the basic feature of Conan is to keep the generated files in Conan cache rather than in some user-specified folder. Conan makes it easy as all versioned binaries with required profiles locate in the same cache folder. Possible to define dependencies per project, per recipe, per package.
Q: Does deployment work with Conan?
A: Not yet. macDeployQt should work out of the box, as it can take packages from any path. winDeployQt requires further investigation, but should not be too complicated there either.
Q: What about the missing parallelism in Conan?
A: Lots of discussion in Conan GitHub, plenty of options given by the community. At the moment, work is focused to Conan 2, after which parallel compression/decompression could be considered. No commitment yet.