[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-frameworks-devel
Subject:    Re: Extend metainfo.yaml files with License Information
From:       Andreas Cord-Landwehr <cordlandwehr () kde ! org>
Date:       2020-08-18 10:52:47
Message-ID: 1741997.uNYYGX2ez1 () weatherwax
[Download RAW message or body]

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




[prev in list] [next in list] [prev in thread] [next in thread]