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

TOOLCHAIN_ENV user variable #131

Closed
cr1901 opened this issue Jul 7, 2019 · 2 comments
Closed

TOOLCHAIN_ENV user variable #131

cr1901 opened this issue Jul 7, 2019 · 2 comments

Comments

@cr1901
Copy link
Contributor

cr1901 commented Jul 7, 2019

One convenient thing omigen had that was dropped recently was the ability to inspect the user's system for toolchains not normally on the path and create a bat/sh file to automatically load the correct environment for these toolchains.

We have discussed bringing this feature back in a more limited form via an environment variable that a user can set called TOOLCHAIN_ENV.

How It Works

  • On Linux, if TOOLCHAIN_ENV is set and not empty (including empty string), the Jinja2 renderer will prepend the generated sh file with a line that sources the file that TOOLCHAIN_ENV points to.
  • On Windows, if TOOLCHAIN_ENV is set and not an empty string, the Jinja2 renderer will prepend the generated bat file with a line that calls the file that TOOLCHAIN_ENV points to.

Open Questions

  • Should this var be tailored for each toolchain nmigen supports?
  • Should this var be split into TOOLCHAIN_SOURCE and TOOLCHAIN_CALL, since we unconditionally generate sh and bat files regardless of host system?
@whitequark
Copy link
Contributor

  • On Linux, if TOOLCHAIN_ENV is set and not empty (including empty string), the Jinja2 renderer will prepend the generated sh file with a line that sources the file that TOOLCHAIN_ENV points to.
  • On Windows, if TOOLCHAIN_ENV is set and not an empty string, the Jinja2 renderer will prepend the generated bat file with a line that calls the file that TOOLCHAIN_ENV points to.

I think this isn't quite right. Build plans can be archived and transferred, say if you need to show an MCVE, and in that case it is the recipient who should be able to configure the build plan. (To a lesser extent this might apply to NMIGEN_verbose and NMIGEN_quiet, arguably.) So it should really be checked by the script itself.

@cr1901
Copy link
Contributor Author

cr1901 commented Jul 7, 2019

I think this isn't quite right. Build plans can be archived and transferred, say if you need to show an MCVE, and in that case it is the recipient who should be able to configure the build plan. (To a lesser extent this might apply to NMIGEN_verbose and NMIGEN_quiet, arguably.) So it should really be checked by the script itself.

Good point.

Should this var be split into TOOLCHAIN_SOURCE and TOOLCHAIN_CALL, since we unconditionally generate sh and bat files regardless of host system?

In that case TOOLCHAIN_{vivado, diamond, trellis, ise, etc}_ENV seems very reasonable.

Sorry, something went wrong.

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

No branches or pull requests

2 participants