Currently most external tools (yosys, fasm2bels) are assumed to be a submodule. However, it would be nice if there was a way (eg environment variable) to specify another location.
With #385 install_fasm2bels will look for the environment variable BFASST_PATH_FASM2BELS and install fasm2bels there if it is not already installed. However, this is primarily used as a caching mechanism for the CI and has some potentially unwanted behavior when run locally. It currently looks in the BFASST_PATH_FASM2BELS directory for a fasm2bels_commit.txt file with the contents containing a commit hash. If the file does not exist with the expected hash contents, the entire directory is deleted and fasm2bels is re-cloned at that directory. This is fine for CI, but a bit problematic locally if the user is working on updates to the external tool (ie they have made changes to their fasm2bels copy) and then we delete it. Given this, we should improve this mechanism before documenting that it can be used for user-supplied external tools.
Currently most external tools (yosys, fasm2bels) are assumed to be a submodule. However, it would be nice if there was a way (eg environment variable) to specify another location.
With #385
install_fasm2belswill look for the environment variableBFASST_PATH_FASM2BELSand install fasm2bels there if it is not already installed. However, this is primarily used as a caching mechanism for the CI and has some potentially unwanted behavior when run locally. It currently looks in theBFASST_PATH_FASM2BELSdirectory for afasm2bels_commit.txtfile with the contents containing a commit hash. If the file does not exist with the expected hash contents, the entire directory is deleted and fasm2bels is re-cloned at that directory. This is fine for CI, but a bit problematic locally if the user is working on updates to the external tool (ie they have made changes to their fasm2bels copy) and then we delete it. Given this, we should improve this mechanism before documenting that it can be used for user-supplied external tools.