You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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?
The text was updated successfully, but these errors were encountered:
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.
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.
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 abat
/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
TOOLCHAIN_ENV
is set and not empty (including empty string), the Jinja2 renderer will prepend the generatedsh
file with a line thatsource
s the file thatTOOLCHAIN_ENV
points to.TOOLCHAIN_ENV
is set and not an empty string, the Jinja2 renderer will prepend the generatedbat
file with a line thatcall
s the file thatTOOLCHAIN_ENV
points to.Open Questions
TOOLCHAIN_SOURCE
andTOOLCHAIN_CALL
, since we unconditionally generatesh
andbat
files regardless of host system?The text was updated successfully, but these errors were encountered: