Am 25.06.20 um 20:43 schrieb Paul Barker:
On Thu, 25 Jun 2020 at 16:36, Stefan Herbrechtsmeier
<ste...@herbrechtsmeier.net> wrote:
Am 24.06.20 um 22:24 schrieb Otavio Salvador:
Em qua., 24 de jun. de 2020 às 17:17, Stefan Herbrechtsmeier
<ste...@herbrechtsmeier.net> escreveu:
The go-mod.bbclass download data from the internet during do_compile. If
you cut the internet connection after a do_fetch the do_compile failed:
Yes, this was the better we could get without hacking go mod tool
itself. It would be nice if you can provide an alternative way to
improve it.
What are the alternative?
a) Add a fetcher to bitbake to create a vendor directory via `go mod
vendor`?
b) Add a `create_go.py` to recipetool and create a recipe per module?
The solutions are related to the npm (a) and python (b) solution.
I don't like a) because it breaks the best practices of OE (for example
one major version per project and avoid embedded dependencies). On the
other side b) isn't so simple because of the circular dependency between
go projects. This means we need a package (recipe) for the source and
the binary.
(a) may not be in line with past best practices but I think it's
better than no change. It at least gives the archiver and licensing
classes a chance to capture the relevant artifacts (if configured
correctly) and so do proper license compliance and/or maintain a
source mirror.
I think the Python method of one recipe per dependency works well for
Python since it's not common to distribute a built artifact which
statically links all those dependencies together. That's often not the
case with rust and golang projects though.
The advantage of go-mod and cargo in compare to npm is that they enforce
semver. This mean you could provide one recipe per major version. The
statically linked dependencies are more a size problem on the target.
I still think one recipe
per upstream project with dependencies fully expressed in the bitbake
recipes would be ideal but as others have said that's fighting a
losing battle.
The main problem is that this package manager work different from the oe
approach. This package managers collect all dependencies at once and
doesn't process package after package.
I try to create one recipe per module (project) but have the problem
that two project depend on each other.
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#139968):
https://lists.openembedded.org/g/openembedded-core/message/139968
Mute This Topic: https://lists.openembedded.org/mt/75063635/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
