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

internal/cfg: GOROOT_FINAL isn't included in KnownEnv, hard to tell if that's a bug or intentional #39819

Open
dmitshur opened this issue Jun 24, 2020 · 3 comments

Comments

@dmitshur
Copy link
Contributor

@dmitshur dmitshur commented Jun 24, 2020

I've noticed the current cfg.KnownEnv list does not include the GOROOT_FINAL environment variable.

We know from #39385 that GOROOT_FINAL has some (albeit indirect) effect on the behavior of the Go command (fortunately, GOROOT_FINAL_OLD no longer does).

Should GOROOT_FINAL be included in cfg.KnownEnv, or is it intentional that it's not listed?

The documentation for KnownEnv is somewhat brief:

// KnownEnv is a list of environment variables that affect the operation
// of the Go command.

It'd be nice to clarify if it's meant to be an exhaustive list or not, and whether some env vars should be intentionally left out or not.

/cc @bcmills @matloob @jayconrod

@dmitshur
Copy link
Contributor Author

@dmitshur dmitshur commented Jun 24, 2020

GOROOT_FINAL has some (albeit indirect) effect

It might be indirect enough to be considered no effect. Perhaps the scope of these env vars are vars that can modify cmd/go behavior only after the Go tree has been installed, and cmd/go tests are out of scope. I wasn't sure from the documentation, which is in large part what this issue is about.

Loading

@bcmills
Copy link
Member

@bcmills bcmills commented Jun 24, 2020

Hmm, that's an interesting question. The main purpose of cfg.KnownEnv is to control which variables may be stored (and read) from the go/env configuration file, but today we do not read GOROOT_FINAL from that file:

func findGOROOT_FINAL() string {
// $GOROOT_FINAL is only for use during make.bash
// so it is not settable using go/env, so we use os.Getenv here.
def := GOROOT
if env := os.Getenv("GOROOT_FINAL"); env != "" {
def = filepath.Clean(env)
}
return def
}

On the other hand, it really does affect the behavior of cmd/go for all binaries that depend on std, not just during make.bash.

Loading

@bcmills
Copy link
Member

@bcmills bcmills commented Jun 24, 2020

Note that there are a few other environment variables that affect compiler behavior that are also not supported in go/env or tracked as test inputs:

  • GO_GCFLAGS (#18222)
  • GOSSAFUNC, GOSSAHASH (#31290; see especially #31290 (comment))
  • possiblyGOCLOBBERDEADHASH, and GO_SSA_PHI_LOC_CUTOFF (but I couldn't find any remaining sites in the code that actually consume these variables, so maybe they're gone now).
  • GSHS_LOGFILE:
    if tmpfile := os.Getenv("GSHS_LOGFILE"); tmpfile != "" {

    if os.Getenv("GSHS_LOGFILE") != "" {
    // Clumsy hack. Compiler writes to this log file,
    // so do not allow use of cache at all.
    // We will still write to the cache but it will be
    // essentially unfindable.
    fmt.Fprintf(h, "nocache %d\n", time.Now().UnixNano())
    }

However, GOROOT_FINAL is somewhat different from those in that it is interpreted directly by cmd/go.

Loading

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants