tinygo version build-tags (duplicate go1.X build-tag functionality)

[archie2x]

Background

You can conditionally compile go source files based on go versions with //go:build lines

require go >= v1.22 //go:build go1.22
require go < v1.22 //go:build !go1.22

Ideally tinygo would offer all the same functionality of big-go and this mechanism would suffice.

Motivation

tinygo offers a subset of the functionality of big-go (rapidly closing gap!)

• it can be difficult to manage downstream projects with release/dev versions of tinygo
• work-arounds are temporary and have to be edited to track tinygo release

Example

While porting u-root, all files for all commands that fail to link with release tinygo (currently 0.32.0) have been marked with //go:build !tinygo && (...)

But, many of these commands now link with tinygo-dev branch, whose version predicts the next release in the (current) form 0.33.0-dev-SHA

Right now, support for using tinygo(-dev) with these commands is being managed by developers with branches.

One solution is to make a more complicated build line and supply the build tags directly, like: //go:build (!tinygo || tinygodev) && (...) and build with tinygo build -tags tinygodev

Problem

Once the next version of tinygo is released, above solution requires modifying source and/or flow to accommodate.

Proposal

I'm proposing tinygo mimic/offer the big-go version build-tags behavior with its own build tags so that we can track its growing support of the big-go functionality. Developers can write //go:build lines that won't have to necessarily be changed as functionality is added to tinygo.

//go:build (!tinygo || tinygo0.33) && (...)

This solution allows specifying a minimum tinygo version, does not require defining custom build-tags, and does not need to be modified once tinygo v0.33.0 is actually released assuming functionality that supported the build isn't removed.

Additional Functionality

Have a way to export the generated version build-tags so that dependent tools can use them.

• big-go does not do this so tinygo generates the go0.X tags itself.
• gobusybox could be modified to use tinygo as its compiler, but use big-go tools, to do so, it needs to forward all the build tags of tinygo (see tinygo: -compiler command line argument (e.g. tinygo) u-root/gobusybox#121)

Additional Thought

tinygo-dev branch should have a tinygodev build tag?

Anyway: supplying build tags, particularly version, only seems like a "win" and doesn't really have any drawback that I can think of.

[archie2x]

Actually, as @aykevl pointed out, I don't think this make sense. The problem is probably the !tinygo build constraints themselves. We don't need more granularity on tinygo version.