From kde-frameworks-devel  Tue Aug 18 10:52:47 2020
From: Andreas Cord-Landwehr <cordlandwehr () kde ! org>
Date: Tue, 18 Aug 2020 10:52:47 +0000
To: kde-frameworks-devel
Subject: Re: Extend metainfo.yaml files with License Information
Message-Id: <1741997.uNYYGX2ez1 () weatherwax>
X-MARC-Message: https://marc.info/?l=kde-frameworks-devel&m=159774797413118

On Dienstag, 18. August 2020 12:34:42 CEST Harald Sitter wrote:
[...]
> > Ouch, yes, the obvious choice, no idea why I did not see that by myself :)
> > Yes, SPDX expressions should be the obvious way to go IMO. For the
> > questions: - for libraries, I agree that the target name should be
> > easiest
> > - for plugins, we could use the library name as it is still a shared
> > object
> > - for applications, we could use the executable name
> > - for anything that is "not changed but only installed" during the
> > compile/
> > install steps, I would say for now that those are out of scope
> > In my understanding, we should strive for encoding all artifacts, but if
> > we
> > miss some we do not state something wrong. Moreover, what we state there
> > should be covered by automated tests (see link above).
> 
> It all sounds reasonable to me.
> 
> I'm pipedreaming a bit ... but given the ultimate goal of stringing
> artifacts to licenses maybe a thing to consider is to actually encode
> this stuff as cmake properties on the actual cmake targets. Perhaps
> not as a first step, but as a longer term goal. The cmake targets
> already know the output name of their artifact is (resolving the
> what-do-we-call-it problem), they also know which sources contribute
> to a target (improving the context capabilities for api.kde.org + the
> plausability tooling could actually look at the targets rather than
> the explicit list of files which of course are subject to human
> error).
> 
> https://cmake.org/cmake/help/latest/command/define_property.html#command:def
> ine_property https://cmake.org/cmake/help/latest/prop_tgt/SOURCES.html

Yeah, I full agree!

In my opinion adding these information to the yaml files is a first step, which 
allows to work separately on the build system tooling part and the API 
documentation part. Actually, for the very same reason 
ecm_check_outbound_license already has a FILES parameter, which later could be 
simply replaced by a TARGET parameter to retrieve files automatically form a 
target ;)

To extend your pipedreaming, I even hope to get same standardized format out 
of this, which simply is generated by an arbitrary build system... :)

As first incremental step, I will prepare a MR for adding functionality to 
api.kde.org and a PoC yaml file for some of the repositories.

Cheers,
Andreas