Hi Slava,
On 22.10.2023 20:34, Vyacheslav Yurkov wrote:
Hey Lukas,
Thanks a lot for the patch. A few questions/comments from my initial
test below.
- I tried it with a go-based backend I have by providing ssh URL to
github. It seems like the GO_IMPORT is set to a module name from go.mod
of my project, which of course fails to fetch it like that, because it's
not a valid URL. How is it supposed to be used?
Your assumption is correct: the GO_IMPORT is taken from the go.mod file.
I've not considered the case where the repo URL is unequal to the module
path. This may require manual rework of the recipe. Another solution
would be to take the source URL from the recipetool. I think there is no
correct solution to this problem, because probably most people might
want to have the original solution, since they are creating recipes from
oss components (i.e. from github).
- I've got about 20 lines like:
INFO: Please add the following line for
'vendor/google.golang.org/protobuf/LICENSE' to a
'lib/recipetool/licenses.csv' and replace `Unknown` with the license:
02d4002e9171d41a8fad93aa7faf3956,Unknown
INFO: Please add the following line for
'vendor/gopkg.in/yaml.v3/LICENSE' to a 'lib/recipetool/licenses.csv' and
replace `Unknown` with the license:
3c91c17266710e16afdbb2b6d15c761c,Unknown
I believe I have to go through all of them manually and set a proper
license in the recipe. Still the questions arises, what should be a
better way to reduce amount of this work? Adding more hashes/licenses to
lib/recipetool/licenses.csv would be a way to go? I'm just afraid that
file might explode if we use it like that...
The file will explode anyway. Thanks 'go'.
Adding more intelligence to the underlying license detection could be an
idea: in your first example, the license file contains actually two
licenses: MIT and Apache. Yocto has no way to detect those cases.
- Could please clarify where does the version from go.mod hide? Is it
taken directly from go.mod? I'm trying to understand what should be the
workflow when a module version should be bumped up in the go.mod. Will
that be reflected in the recipe in any way?
No, currently the go-version doesn't play a role ATM. Except one case
when you have a go.mod file with go < 1.17. These go.mod files don't
include indirect dependencies.
I hope you might find this helpful and thanks for testing!
Cheers,
Lukas
Thanks,
Slava
On 17.10.2023 15:26, [email protected] wrote:
From: Lukas Funke <[email protected]>
This patch series adds a recipetool handler in order to create 'go'
recipes.
Each recipe contains a list of dependencies in their SRC_URI
variable which are derived from the projects `go.mod` file. For each
dependency the corresponding license file uri/hash is added.
The recipe may not work ad-hoc, but is a good starting point to create
a working recipe and have a working offline-build.
Lukas Funke (4):
classes: go-vendor: Add go-vendor class
selftest: recipetool: Add test for go recipe handler
recipetool: Ignore *.go files while scanning for licenses
recipetool: Add handler to create go recipes
meta/classes/go-vendor.bbclass | 135 ++++
meta/lib/oeqa/selftest/cases/recipetool.py | 163 +++++
scripts/lib/recipetool/create.py | 2 +-
scripts/lib/recipetool/create_go.py | 730 +++++++++++++++++++++
4 files changed, 1029 insertions(+), 1 deletion(-)
create mode 100644 meta/classes/go-vendor.bbclass
create mode 100644 scripts/lib/recipetool/create_go.py
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#189623):
https://lists.openembedded.org/g/openembedded-core/message/189623
Mute This Topic: https://lists.openembedded.org/mt/102017388/21656
Group Owner: [email protected]
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
