Qt Contributors Summit 2022 - Program/Conan - a package manager for Qt?
State of the endeavour, discussion about future
- Kai Köhne
(Taken by Samuel Gaist)
What has been done ?
- Missing a convenient way to get Qt and dependencies
- Bridge the gap between binary and source deliverables
- Command line and script friendly
- Simplified build instructions for your application
- Getting projects to be built by users can be a pain for them because of the various way required to get dependencies
- Side note: QIW now also have support for command line now
- Rather than having a long list of dependencies and the various ways to get them, what about having a one liner for users to call and get them all?
- Reduce number of binaries
- More flexibility for add-ons (Qt or other)
- Source only releases
- Independent release schedule
- Binaries & source builds
- Large list of existing packages
- Support for various build systems
- Complexity (e.g. support for various build system makes it possible to do things in several different ways but none where very satisfactory)
- Only Qt 6 packages (Qt 6.2 currently, the complete automation is not yet in place)
- Cross-compilation is WIP in Conan
Opportunities (i.e. to be done)
- Qt sources: Third-party code may be removed in the future not all of them though depending on the patching required
- IDE Integration (i.e. automatic dependency installation)
- Installer integration
- Vendor lock-in (server side is really limited as it is the main product is JFrog)
- `conan-center` vs Qt Company server (integration with COIN, etc.)
- Low adoption (less than a 1000 users in the first half of the year and most of them are in Finland)
Have you personally tried Conan ?
- Not used it yet however could be useful to setup machine for newcomers
- There are no instructions on how to use it
- Not made it officially recommended yet
- Useful for multiple dependencies project but not really for pure Qt projects
- it does not simplifly things (basically call qtenv2.bat/msvc.bat -> done, or just add Qt/bin to path) . You then have all modules in path instead of some per-project directory with a long path name...
- I tried it, but quickly gave up. But that tryout was a while ago. My main pain point was, that I had to copy paste commands that were ~5 command line lines long so that conan build "something" in some "magic directory" on my hard disk. It was completely unclear what it did and where things ended up and how I use the resulting Qt. But as said it has been a while since I tried
- i tried it and worked quite good for me
- for conan you just need a conanfile with the packages you need + a cmake config to do some magic, that wasn't complicated in my opinion
- Conda / Mamba could be a better alternative because simpler
- hot take. add a configure --conan option. which would download and install conan, and then use it to download prebuilt qt, or configure it for building + building it
- Would require qt5.git in any case
- Would at least make it more prominent
- Just my 2 cents: I'm using this in a project that (among other targets) cross-compiles to Android.
If conan hasn't broken the build again (which happens quite often) it's a joy to have protobuf, grpc, boost etc. (cross-)built automagically. If the build breaks its frustrating to find the cause. Handling of host tools for cross platform builds is also problematic.
The documentation is "lacking", for cmake the 1.x generators are deprecated (won't exist in 2.0), the 2.x generators are already usable in 1.x but are declared as unstable (moving target) and are terribly documented. Lots of magic python properties only found by searching the github issue tracker.
However I've no yet tried to add Qt via Conan, still using the online installer for this.
answer: Agreed -> virtual environment generators are recommended
- Do we solve an actual problem users have ?
Ran out of time to answer that one