Allow linking against wasmtime's minimal build

[effulgentsia]

Wasmtime releases include precompiled "full" and "min" binaries. I'd like to create a Go application that uses the min binary. My main obstacle to this is that the Go source files call C functions that don't exist in the min binary, causing compilation to fail during linking.

This PR splits those Go functions out into separate files that are gated behind build tags.

[alexcrichton]

Thanks for the PR! This is something that I'm not personally very well versed in with the Go ecosystem, however, so I'm a bit hesitant about this. Some concerns I have are:

• There's no testing in CI for this, so this is something that I believe could easily regress over time.
• Right now all the features here are "negative features" where something is asserted to not exist. Personally I've had a bad time in other contexts/build systems when things are framed this way and I find everything is much more composable when things are framed in a "positive way", or asserting that a feature does exist. Is this behavior here idiomatic in Go? Are there alternatives of how to include optional features?
• How are users expected to use this? Will *-min binaries need to be checked into the releases?

[effulgentsia]

Will *-min binaries need to be checked into the releases?

I opened #273 for just that part.

There's no testing in CI for this

I think we'll need the v43 release of wasmtime to come out first, since the gc_support setter is needed to be able to exercise the minimal build. But I can add the test coverage to this PR after that's out.

Right now all the features here are "negative features"

What do you think if we keep the .go files split as in the current PR, but instead of gating them on the corresponding feature, we just gate them on a single wasmtime-minimal build tag? It would still be a negation (as in //go:build !wasmtime-minimal), but at least it wouldn't be a negation of something that starts with no_. Go build tags always default to false unless explicitly set, so negation constraints are common, and in this case I'm assuming we want to preserve the full build as the default case when no build tag is passed.

I originally thought per-feature tags would be nice in case anyone wants to use a custom compiled wasmtime binary that's somewhere in between minimal and full, but if someone is doing that, they already would need a more complex build script and can use other techniques than Go build tags to control it: for example, their build script could just delete the unwanted .go files from the vendor directory.

[effulgentsia]

This PR is now not mergeable. I'd like to do some cleanup on it first, but it now has test coverage.

[effulgentsia]

I'm done with the cleanup I wanted to do, but (in order for the test to work) this PR duplicates changes from #271 and #273. I can rebase this if/when those get merged separately.

[alexcrichton]

Do you know if there's any way for cgo in Go to feed into the build process at all? For example can a #define be detected in cgo and somehow feed into what functions or files are compiled in Go? Overall I'm pretty wary of this functionality because it's going to be a significant maintenance burden over time (and there's very little bandwidth to maintain this repo as-is).

just gate them on a single wasmtime-minimal build tag

While this doesn't literally contain an english-language double-negative it still effectively does the same thing where turning on a feature disables functionality, as opposed to the other way around. That makes this not composable with other features/dependencies, for example.

Given Go's build system I don't think there's really a way around this, however. One way might be to just go ahead and separate the files and make it easier for forks to delete files and swap in separate libraries? Not that that's a great solution...

W.r.t. #273 one of the worries I have about that is that this repository's releases are already massive with hundreds of MBs of artifacts. Merging that would increase the size even further since there's yet-more artifacts.

---

Personally I feel that this is more-or-less a situation that the combination of Go & C is not well-equipped to handle. I don't know how other Go libraries handle something like this, though.

[effulgentsia]

One way might be to just go ahead and separate the files and make it easier for forks to delete files and swap in separate libraries? Not that that's a great solution...

That works for me. For my application, it's no problem at all for my app's build script to download the min binary to replace the full one and to delete the unwanted .go files from its local vendor directory. I updated the PR to only separate the files, and then made test.sh perform a similar flow to how an application would use it. The test.sh script can certainly be cleaned up to be made much nicer, but before I proceed with that, does this approach address your concerns?

[effulgentsia]

This is ready for another review.

Do you know if there's any way for cgo in Go to feed into the build process at all?

I don't. So this PR instead just splits the files and leaves it to the application to delete unwanted files. The test shows this now.

one of the worries I have about that is that this repository's releases are already massive with hundreds of MBs of artifacts

This PR now has the test downloading the minimal build artifact during test execution without it needing to be committed to this repo.

[alexcrichton]

Oh yeah wow this looks great, thanks for this! Everything here looks good to me so I'm going to go ahead and merge, thanks again for working with me on this!