Originally, cmd/compile implemented a lot of logic for resolving import paths, finding installed packages, etc. internally. Nowadays, this is all handled by cmd/go instead, which then invokes cmd/compile with the -importcfg option. However, a lot of historical code and flags still exist within cmd/compile, and it's not obvious which use cases still matter.
The proposal here is to require build systems that want predictable behavior from cmd/compile must use -importcfg. If -importcfg is not used, then cmd/compile's handling of import paths is unspecified and subject to change at the discretion of the compiler team.
In practice, I don't anticipate the fallback logic to change much from today (to avoid breaking test/run.go or compiler dev workflows). But the current code has grown convoluted and has questionable code paths, and it would be easier to cleanup if we could constrain the set of supported options.
The text was updated successfully, but these errors were encountered:
Originally, cmd/compile implemented a lot of logic for resolving import paths, finding installed packages, etc. internally. Nowadays, this is all handled by cmd/go instead, which then invokes cmd/compile with the -importcfg option. However, a lot of historical code and flags still exist within cmd/compile, and it's not obvious which use cases still matter.
The proposal here is to require build systems that want predictable behavior from cmd/compile must use -importcfg. If -importcfg is not used, then cmd/compile's handling of import paths is unspecified and subject to change at the discretion of the compiler team.
In practice, I don't anticipate the fallback logic to change much from today (to avoid breaking test/run.go or compiler dev workflows). But the current code has grown convoluted and has questionable code paths, and it would be easier to cleanup if we could constrain the set of supported options.
The text was updated successfully, but these errors were encountered: