Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add stubs for compiling without wasmtime / without cgo #3664

Merged
merged 1 commit into from
Nov 22, 2022

Conversation

justinsb
Copy link
Contributor

This allows us to compile kpt without cgo support; wasm support is in
alpha and we have to opt in to wasm support and the wasmtime runner
anyway.

We can likely add an exec-based runner here instead in future (though
we already have the nodejs one).

This allows us to compile kpt without cgo support; wasm support is in
alpha and we have to opt in to wasm support and the wasmtime runner
anyway.

We can likely add an exec-based runner here instead in future (though
we already have the nodejs one).
@mortent
Copy link
Contributor

mortent commented Nov 17, 2022

Change looks good, but just a few questions:

  • This would mean that our regular published binaries will no longer include wasm support. Is the idea that users who want wasm support should build it from source?
  • Should we also update the goreleaser spec for this to avoid enabling cgo?

@justinsb
Copy link
Contributor Author

This would mean that our regular published binaries will no longer include wasm support. Is the idea that users who want wasm support should build it from source?

So today if you compile with GCO_ENABLED=0, kpt fails to build. This is ensuring it will build, and yes, built-in wasm support will not be available. However, the nodejs support is still available.

I see this as a first step only; we fix a scenario in which the compile fails. I would like to continue to support wasm functionality even with CGO_ENABLED=0, one way is to build a separate binary that wraps wasmtime. But that would have to be built with CGO_ENABLED, and we already have nodejs there, so I don't know whether that is a win.

Should we also update the goreleaser spec for this to avoid enabling cgo?

We can do, particular if cgo is causing other problems, but we don't have to. I think given that wasm is in alpha, and given that the nodejs support is available also, it's a reasonable thing to do, but I don't think this PR forces things either way (other than giving us the option to run with CGO_ENABLED=0!)

@justinsb justinsb merged commit 353766e into kptdev:main Nov 22, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants