Akademy/2018/Conan Workshop

General Approach

Conan needs one recipe for one package.

KDE Frameworks and git repositories in general can contain multiple separately-packaged libraries.

General breakdown, a Framework could have something like:

• Core
• Gui
• Widgets
• Tools

libraries. We want those to result in separate conan packages. e.g. the "kconfig" git repository / KDE framework should result in packages for "KF5ConfigCore" and "KF5ConfigGui" (the two separate libraries that are possible).

Many distributions already break up our packages (for good reason) and this would also support efforts with Kirigami and mobile in general, in support of our goals.

Conan is able to package Boost which has many different submodules (e.g. boost_accumulators), so the technique employed here may be helpful.

With extra support in our own CMake modules to split out the libraries into separate Components (so that we could avoid confusion in CMake with trying to install all other libraries when we're just trying to install one)

Generating Conan recipes

We'd want to generate these recipes from a template, driven by the metadata that already exists. Otherwise we now have yet another source of dependency metadata that needs to be maintained.

But as part, we'd want to move the dependency metadata to the per-repo YAML files to replace kde-built-metadata as authoritative. Could then generate an all-in-one file for CI/kdesrc-build.

Example

KAuth (Tier 2) depends on KCoreAddons (Tier 1)

Issues

• How to handle two libraries in a framework that share dependencies to files that would be packaged. In cases where the multiple libraries don't break up into disjoint subsets.
• How to handle the multiple Conan recipes we'd likely need:
  • namespaced at top-level in source dir,
  • a conanfile.py in separate dirs from source toplevel (core/, /gui, etc)
  • a separate dir for Conan entirely in the source
• When to split out bin/libexec types of tools into a separate KF5Foo-Tools package, as some distributions already do?
• What about conditional compilation in CMake, that hide find_package calls? If we fix this, then we can use the YAML file to list dependencies and then push those dependencies automatically into CMake. But fixing this might require breaking apart frameworks even further somehow.
• Need to continue to ensure Conan is optional to support distributions that don't use pip, npm, similar things for package installation.
• Some of the changes we'd need here are already changes we'd need to make for other reasons (e.g. supporting static library builds)
• Need to account for all the possible QStandardPaths types (xdgdata, bin, data, etc.) in Conan recipes

Frameworks are not aware of their dependency tree

This should be the job of a distribution, but given we general idea is to move toward a kind of SDK, then CMake/Conan becomes a distribution. This is unfortunate, but is an increasingly unavoidable issue. For the CI, we built such complete information. Why? Because the CI is in a way a distribution too.

To generate AppImages, we also need this information. We also need for generating Android APKs. In those 3 case, there is no proper Linux distribution involved. There is unsustainable duplication of this metadata across these different platforms. On top of *that*, most distributions split even frameworks into smaller packages such as `kconfigcore` and `kconfiggui`.

Adding Conan on top of this existing duplication would involve another row of duplication with a different granularity.

Even in the frameworks, this information is partially available in different places. There is the YAML file used by the doc, then `find_package` on the KF5 namespace and `find_package` for individual frameworks. Add to that we should also put this information in the config.cmake.in file to avoid dependencies warn they indirectly require a package they don't know and we have 4 places storing part of the information (or it's fully missing).