> I suspect this will give you trouble over time. That's the question I've been pondering a lot lately. I know for sure that trying to keep up with the go tool evolution *is* a lot of trouble. I'm trying to experiment with alternatives to get some sense for how they actually compare. Using go/build is what GopherJS currently does and it lacks feature parity with the go tool (which I think is intentional?). go/packages is a bit better and works reasonably for code analysis/editor support purposes, but doesn't lend itself <https://github.com/gopherjs/gopherjs/pull/948#issuecomment-695084718> for third-party compilers, and things like file embedding would still most likely require rebuilding from scratch (not 100% sure here, I only briefly skimmed the proposal at this point). Hijacking toolchain calls is the last option I haven't explored and in theory it sidesteps pretty much go tool-level problems.
> For example, it expects cmd/link to create a build ID that can be recognized by cmd/internal/buildid. It expects to be able to pack additional objects into archive files (see packInternal in cmd/go/internal/work/gc.go). This is a useful data point. Currently GopherJS uses its own bespoke format for intermediate artifacts, maybe it's one more reason to actually switch to proper object files. It works for WebAssembly, so we could probably make it work for JS as well. Is it worth the trouble? Maybe not, one way to find out :) Another way to approach this is to implement a generic "third-party" toolchain with a simplified set of assumptions for all other compilers to use. From that perspective posing as gccgo would've been ideal if not for 1) gcc flags are a pain to parse in Go and 2) it doesn't produce calls to build standard library, since gccgo has it pre-built (as far as I understand). пн, 11 янв. 2021 г. в 19:14, Ian Lance Taylor <i...@golang.org>: > On Mon, Jan 11, 2021 at 11:03 AM Alexander Zhirov <al...@nevkontakte.com> > wrote: > > > > At the moment there are at least three alternative implementations of Go > that I know of (and there are probably some I don't): gccgo, tinygo and > gopherjs. Of the three, only gccgo is supported by the go tool out of box. > Looking at the source code, gc ang gccgo have their own implementations of > the toolchain interface. > > > > The other two essentially reimplement the built system using go/build > package, and, based on my experience with GopherJS, keeping up with changes > to the upstream Go build tooling (modules, file embedding, etc.) is a lot > of effort. > > > > Out of interest, I was investigating what would it take for GopherJS to > delegate build system details to the Go tool and only provide alternative > implementations of compile/link tools. For prototyping purposes -toolexec > flag allows me to insert a proxy that intercepts compiler/linker > invocations and invokes GopherJS as required. The nice thing is that no > GopherJS-specific code needs to exist in the cmd/go codebase. > > > > I'm currently at a very early stage, but it seems to be working out. > Before I spend too much time though, I'd like to probe people's opinions of > a few questions: > > > > 1) Is the idea of treating cmd/compile, cmd/link (and so on) interfaces > as an extension point a reasonable one? I expect that they are going to > change between releases, but probably fewer than the build system as a > whole. > > I suspect this will give you trouble over time. When the go tool > invokes cmd/compile and cmd/link, it expects them to behave just like > the ordinary cmd/compile and cmd/link commands. For example, it > expects cmd/link to create a build ID that can be recognized by > cmd/internal/buildid. It expects to be able to pack additional > objects into archive files (see packInternal in > cmd/go/internal/work/gc.go). There may be other complex dependencies, > and certainly more will be added over time. > > Ian > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CALFPu54Po-SNooeKXuy%3DHKdxgbUv%2BnU3mRpMwUC7UFgJDCBk%2Bw%40mail.gmail.com.
