Open simulance opened 1 year ago
This appears to be because github.com/klauspost/pgzip
doesn't have a go.mod
file so we don't attach dependencies properly.
I suppose it needs to try to figure out that it should be doing that from the source, which I think might be tricky to fully generalise (the module location isn't extant in the import path). Alternatively maybe we allow a deps
argument on go_repo
to let the user hint this where necessary.
Ah ok we already have that, it's requirements
. The following works:
go_repo(
module = "github.com/klauspost/compress",
version = "v1.16.7",
)
go_repo(
module="github.com/klauspost/pgzip",
version="v1.2.6",
requirements = ["github.com/klauspost/compress"],
)
$ plz build ///third_party/go/github.com_klauspost_pgzip//:pgzip
Build finished; total time 11.95s, incrementality 62.5%. Outputs:
///third_party/go/github.com_klauspost_pgzip//:pgzip:
plz-out/gen/third_party/go/github.com_klauspost_pgzip/pgzip.a
I don't think that fixes the cross-compile issue which seems more generic... We've talked a few times about revisiting how architectures work in the face of things like go_repo
that extensively use subrepos.
Attempt 1: on
darwin_arm64
Attempt 2: on
darwin_arm64
cross-compiling tolinux_amd64
Attempt 3: on
linux_amd64
The standard
go
command builds it fine but there appears to be no way of building it using Please 17.3.0.Repro script
``` plz init mkdir plugins cat > plugins/BUILD << EOF plugin_repo( name = "go", revision="v1.8.1", ) EOF cat >> .plzconfig << EOF [Plugin "go"] Target = //plugins:go GoTool = //third_party/go:toolchain|go EOF mkdir -p third_party/go cat > third_party/go/BUILD << EOF subinclude('///go//build_defs:go') go_toolchain(name='toolchain', version='1.20.7') go_repo(module="github.com/klauspost/compress", version="v1.16.7") go_repo(module="github.com/klauspost/pgzip", version="v1.2.6") EOF plz build ///third_party/go/github.com_klauspost_pgzip//:pgzip plz build ///third_party/go/github.com_klauspost_pgzip//:pgzip -a linux_amd64 ```