Closed umarcor closed 3 years ago
This is quite annoying to implement nicely because -m
takes a filename and tries several permutations of it, but you're using it like it takes a plugin name. In my view, some refactoring is necessary first to clearly separate these two possible kinds of inputs. (Perhaps have one option that takes a full filename, and another that takes a plugin identifier?)
@whitequark I think I didn't explain myself properly. The proposal is not about discovering and reporting the list of plugins that are available as modules (external shared libraries). This is about changing the error message when option -m
is used in a Yosys built without plugin support. Attempting to use that option produces an error ("This version of yosys is built without plugin support"), which does not let the user know that some plugins/modules/frontends are built-in, even though external ones cannot be used.
I believe that the feature you were referring to is #1640.
NOTE: on Windows, ghdl-yosys-plugin needs to be built-in, because yosys does not support external modules. However, the recommended approach on GNU/Linux is to use ghdl-yosys-plugin as an external module/plugin.
When Yosys is built without dynamic plugin loading support, using option
-m
produces the following error:However, some plugins/frontends might be built-in. For example, ghdl-yosys-plugin can be built either with Yosys or as a shared library. Using
-m ghdl
in the former case produces the mentioned error. That's partially misleading becauseghdl
commands are available. Instead, I would like to propose listing the built-in plugins. For example:Ref open-tool-forge/fpga-toolchain#58 #1640
Steps to reproduce the issue
PATH=/path/to/toolchain/bin:$PATH yosys -m ghdl
/cc @edbordin