Create Task
Maniphest T9450

Add more info to the metainfo.yaml file for Conan and CMake
Open, Needs TriagePublic
Actions

Description

After the Conan BoF at Akademy 2018 (see notes here) we've discovered that we need more information in the metainfo.yaml file for Conan and CMake, in order to reduce duplication.

An initial list of things that we need are:

  • Name - the project name
  • Licence - the project licence
  • URL - the project home page, most likely the API site
  • Version - the project version
  • Dependencies - a list of projects that this project depends on
  • Optional Dependencies - not strictly needed to build this project (e.g. test or docs related dependencies)
  • Libraries - that the project links against
  • Artifacts - list of packages that result from this project (e.g. libraries, executables)

We still need to figure out how exactly we would parse this information in CMake and Conan, but an initial example for Conan is available here.

The Artifacts list needs also to define how they depend on one another, so if a user uses one of them, the package will know what else it needs, and Conan will download it for the user.

Related Objects
Search...

obogdan created this task.Aug 19 2018, 3:25 PM
bcooksley added a comment.Aug 19 2018, 3:57 PM

In terms of Dependencies (including the Optional ones) is there a particular format that has to be followed for Conan, or could we keep this to be something which follows the usual conventions we have across KDE?

In terms of Libraries / Artifacts, i'd suggest using Uses and Provides here to make it a little more intuitive for someone who hasn't seen this before.

For those who haven't seen an existing metainfo.yaml file, this is what we have currently:

maintainer: ltoscano
description: Documentation generation from docbook
tier: 2
type: functional
platforms:
    - name: Linux
    - name: FreeBSD
    - name: Windows
    - name: MacOSX
portingAid: false
deprecated: false
release: true
cmakename: KF5DocTools

public_lib: true
group: Frameworks
subgroup: Tier 2

I'm wondering if the Provides bit can be automated to a certain extent as well, given that libraries meant for use elsewhere should be exported by CMake, which means we'll have *Config.cmake files available.

Fuchs removed a subscriber: Fuchs.Aug 19 2018, 4:41 PM
obogdan added a comment.Aug 19 2018, 4:56 PM

A Conan package has the following reference format: <name>/<version string>@<user>/<channel>. All these fields are strings, and can be anything that we want. I've thought so far that we should use the project name as package name. But considering T9451, that cannot be like this.

I'm ok with the terms Uses and Provides replacing Libraries and Artifacts.

The Provides part can be a separate file generated by CMake, but then we'd have to commit generated files, and I'm against that. I'm thinking that the Provides field would provide the strings with the names of the artifacts that CMake will fetch and use.

Here's an example of what I have in mind:

maintainer: mdawson
name: kconfig
description: Configuration system
license: LGPL v2.1
url: https://api.kde.org/kconfig/
version: 5.50.0

tier: 1
type: functional
platforms:
    - name: Linux
    - name: FreeBSD
    - name: Windows
    - name: MacOSX
    - name: Android
portingAid: false
deprecated: false
release: true

dependencies:
 - name: extra-cmake-modules
   version: 5.50.0
 - name: qt-gui
   version: 5.8.0
 - name: qt-xml
   version: 5.8.0

provides:
 - qmake: KConfigCore
   cmake: "KF5::ConfigCore"
 - qmake: KConfigGui
   cmake: "KF5::ConfigGui"
cmakename: KF5Config

public_lib: true
group: Frameworks
subgroup: Tier 1

Added

  • name
  • license
  • url
  • version
  • dependencies

Renamed

  • libraries to provides

This is a rough idea of what I have in mind. But now that I think more about it, I'm realizing that the Dependencies actually apply to the elements in Provides. KConfigCore does not need Qt Gui, but KConfig Gui does.