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