Hi Konrad,
Am 24.12.21 um 11:36 schrieb Konrad Weihmann:
I had a look at the failures and most of them are fairly easy to fix -
all but the go recipes like influxdb.
The go class doesn't work without network by default if the project
doesn't provide a vendor folder.
I'm not sure how to deal with that, so there aren't that many options here.
This is a common problem for all language specific package managers
(python / pip, Node.js / npm, Rust / Carge, go) and we need a common
solution.
Either
- inject all the needed with a fixed revision, but that would prevent
devtool from catching updates to them properly
This is possible if we extend recipetool to add the dependencies to the
recipe. Rust and npm are using this option and I have a WIP to improve
the npm solution. But in any case we loose a lot of advantages of OE.
- create recipes for all of them and pray that there won't be a circular
dependency in any of them
The circular dependency is only the least problem and could be fixed by
splitting the dependency and code into separate recipes. The main
problem is the huge increase of recipe count and parse time. Furthermore
we need the possibility to test recipe updates of dependencies. Python
is using this option.
- allow go to work with network (the least favorable option IMO)
This is how the current go and especially go-mod class work.
in the case of influxdb for instance we are talking about
github.com/peterh/liner
golang.org/x/crypto
github.com/influxdata/influxql
github.com/influxdata/flux
github.com/BurntSushi/toml
github.com/influxdata/usage-client
golang.org/x/text
go.uber.org/zap
github.com/klauspost/pgzip
github.com/prometheus/client_golang
github.com/jsternberg/zap-logfmt
github.com/mattn/go-isatty
collectd.org
github.com/bmizerany/pat
github.com/dgrijalva/jwt-go/v4
github.com/gogo/protobuf
github.com/golang/snappy
github.com/tinylib/msgp
github.com/opentracing/opentracing-go
golang.org/x/sync
github.com/apache/arrow/go/arrow
github.com/pkg/errors
google.golang.org/grpc
github.com/kraj/xxhash
github.com/influxdata/roaring
github.com/xlab/treeprint
golang.org/x/time
golang.org/x/sys
github.com/jwilder/encoding
github.com/dgryski/go-bitstream
where especially the golang.org/x modules are known to have circular
dependencies like x/a relies on x/b, while x/b requires x/c and x/c
needs x/a for building.
Isn't the circular dependencies problem mainly a problem of the native
packages? In many cases the dependency only exists at compile time of
the main project and not at compile time of the dependency itself. In
case of a native package all dependency sysroots need to be finished
before the recipe sysroot itself.
Regards
Stefan
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#160005):
https://lists.openembedded.org/g/openembedded-core/message/160005
Mute This Topic: https://lists.openembedded.org/mt/87909311/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
