On Fri, 6 May 2022, at 18:10, [email protected] wrote: > > Hello all, > > I just posted a series of patches for the purpose of generating recipies for > a go offline build: > > [PATCH 1/5] recipetool-create: add ensure_native_cmd function > (openembedded.org) > <https://lists.openembedded.org/g/openembedded-core/message/165323> > [PATCH 2/5] create_npm: reuse ensure_native_cmd from create.py > (openembedded.org) > <https://lists.openembedded.org/g/openembedded-core/message/165325> > [PATCH 3/5] poky-meta: add go vendor class for offline builds > (openembedded.org) > <https://lists.openembedded.org/g/openembedded-core/message/165324> > [PATCH 4/5] recipe tool: add go recipe generator (openembedded.org) > <https://lists.openembedded.org/g/openembedded-core/message/165326> > [PATCH 5/5] oe-selftest: add go recipe create selftest (openembedded.org) > <https://lists.openembedded.org/g/openembedded-core/message/165327> > > The series generates recipies of the following form (grpc-web as an example): > >> SRC_URI = "git://${GO_IMPORT};nobranch=1;name=${PN};protocol=https \ >> >> file://go.mod.patch;patchdir=src/${GO_IMPORT} \ >> >> >> ${@go_src_uri('github.com/cenkalti/backoff',path='github.com/cenkalti/backoff/v4')} >> \ >> >> ${@go_src_uri('github.com/desertbit/timer')} \ >> >> ... >> >> #TODO: Subdirectories are heuristically derived from the import path and >> might be incorrect. >> >> # github.com/cenkalti/backoff/[email protected] => >> 6b0e4ad0cd65431b217393bff47d1dff727b264b >> >> SRCREV_github.com.cenkalti.backoff.v4 = >> "6b0e4ad0cd65431b217393bff47d1dff727b264b" >> >> GO_MODULE_PATH[github.com.cenkalti.backoff.v4] = >> "github.com/cenkalti/backoff/v4" >> >> GO_MODULE_VERSION[github.com.cenkalti.backoff.v4] = "v4.1.3" >> >> # github.com/desertbit/[email protected] => >> c41aec40b27f0eeb2b94300fffcd624c69b02990 >> >> SRCREV_github.com.desertbit.timer = >> "c41aec40b27f0eeb2b94300fffcd624c69b02990" >> >> GO_MODULE_PATH[github.com.desertbit.timer] = "github.com/desertbit/timer" >> >> GO_MODULE_VERSION[github.com.desertbit.timer] = >> "v0.0.0-20180107155436-c41aec40b27f" >> > > > How it works: > > the recipetool resolves the go-module-path for each dependency in the go.mod > file to a corresponding src-url (mostly git repository urls, but other vcs > would work as well). The recipetools also resolves the (pseudo)-semver to the > corresponding git commit. git-url and commit hash are added to the generated > go-recipe and processed later during build by the go-vendor.bbclass. During > 'unpack' the bbclass copies the fetched dependency sources to the 'vendor' > subdirectory and generates a 'modules.txt' manifest. > Most of my test projects worked right away. However, I'm sure that I missed > some corner cases, as I'm not a go expert. Thus, I would be grateful for your > opinion on my approach. >
The implementation approach looks fine to me and it's what I had in mind too. What do you guys feel about taking the same approach in cargo-bitbake - writing this tool in go and maintaining it as such? I was just starting doing that but I stopped seeing this. There is an argument that go people would be able to help more in a go project while maintaining support for go packages in yocto/OE. And that seems to have worked fine in cargo/rust. Andrei
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#1543): https://lists.openembedded.org/g/openembedded-architecture/message/1543 Mute This Topic: https://lists.openembedded.org/mt/90782883/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-architecture/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
