Re: License reporting for golang (and rust)

Robert Berger


My comments are in-line

On 30/06/2020 14:37, Irving ST wrote:
For anyone else having the same problem, here's what I eventually did
for my go stuff:
I created a bbclass containing a task that gets inherited by all
packages, but the task only does some work when it detects that it is
inherited by a golang recipe.
The task basically sets up GOPATH and calls - this tool populates all the source
dependencies and generate a trash.lock file in the repository.
Then I used to generate a
json report that can be postprocessed with python.
Is your work available somewhere in the public? I would like to give it a try with dunfell 3.1.1 and influxdb.[1] Also it would be interesting what happens if you include a prebuilt go executable[2].

[1] (from khem and slightly hacked)


To me it seems that Go used the vendor directory approach in the past,
and there are multiple tools that can be used for this; and nowadays
go seems to have switched to a different approach called go modules.
It looks like master and dunfell 3.1.1 support go modules now.[3][4]


Now we have both go dep and go modules support ;)

With this multiple tools and methods of managing dependencies, I am
not sure whether it is feasible to integrate this in Yocto at all -
though I think I have seen mailing list posts on meta-virtualization
adding vendor information to their recipes, so maybe some progress is
happening there.
Currently arm 32 Golang support is broken in meta-virt (docker), but I am confident it's going to be fixed soon.[5]


Best regards,
Irving Tjiptowarsono


Join to automatically receive all group messages.