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

duplicate big-go version tags functionality [ fix #4391 ] #4389

Closed
wants to merge 2 commits into from

Conversation

archie2x
Copy link
Contributor

@archie2x archie2x commented Aug 7, 2024

[ see #4391 for motivation ]
This attempts to duplicate big-Go go1.X build tags in tinygo with a series of build tags in the form tinygo0.1,tinygo0.2,...

Also adds a '-full' command-line flag to see all of the tags.

% ./build/tinygo info -json -full
{
  "goarch": "arm64",
  "goarm": "6",
  [...]
  "build_tags": [
    "darwin",
    "arm64",
    "tinygo",
    "purego",
    "math_big_pure_go",
    "gc.precise",
    "scheduler.tasks",
    "serial.none",
    "tinygo0.1",       <---
    "tinygo0.2",       <---
    [...]
    "tinygo0.32",      <---
    "tinygo0.33"       <---
  ],
  "garbage_collector": "precise",
  "scheduler": "tasks",
  "llvm_triple": "arm64-apple-macosx11.0.0"
}

TODO:

  • tests
  • Version specification is constantly confusing. I'd be inclined to create a separate package for clarity s.t. the constants were of the formtinygoVersion.Major etc. instead of goenv.VersionMajor etc.
  • define tinygo-dev build tag if "-dev" ?
package tinygoVersion

const Major = 0
const Minor = 33
const Patch = 0
const Dev = "-dev" // "" for release

@aykevl
Copy link
Member

aykevl commented Aug 7, 2024

I'm not entirely convinced we should be doing this. Can you explain why this is needed (and why you can't just use the latest tinygo for example)?

@archie2x archie2x changed the title duplicate big-go version tags functionality duplicate big-go version tags functionality fix #4391 Aug 7, 2024
@archie2x
Copy link
Contributor Author

archie2x commented Aug 7, 2024

I'm not entirely convinced we should be doing this. Can you explain why this is needed (and why you can't just use the latest tinygo for example)?

Thanks! Sorry: it was an early-morning PR. See Issue #4391 where I tried to illustrate the motivation.

@archie2x archie2x changed the title duplicate big-go version tags functionality fix #4391 fix #4391: duplicate big-go version tags functionality Aug 7, 2024
@archie2x archie2x changed the title fix #4391: duplicate big-go version tags functionality fix #4391 : duplicate big-go version tags functionality Aug 7, 2024
@archie2x archie2x changed the title fix #4391 : duplicate big-go version tags functionality duplicate big-go version tags functionality [ fix #4391 ] Aug 7, 2024
@archie2x
Copy link
Contributor Author

archie2x commented Aug 9, 2024

As mentioned in #4391, I agree this doesn't make sense for now.

@archie2x archie2x closed this Aug 9, 2024
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.

2 participants