search

YosysHQ / yosys

Yosys Open SYnthesis Suite
https://yosyshq.net/yosys/
ISC License
3.37k stars 871 forks source link

Allow loading plugins "by name" from more than one source (alt: add a search path for plugins) #2545

Open thoughtpolice opened 3 years ago

thoughtpolice commented 3 years ago

When yosys is invoked with the flag -m foo or the command plugin -i foo is run — that is, with a non-absolute path to a dynamically loadable library — the loader will look for a file named foo.so by default in (among other places) /usr/share/yosys/plugins, where $PREFIX/share/yosys is also known as YOSYS_DATDIR.

The intention of this design is that this single location is global and shared across the system; tools like yosys-ghdl or yosys-bluespec should by default be installed into such a location by invoking cp ... $(yosys-config --datdir)/plugins or whatever after compilation. Package managers should put the .so files in this directory, and so forth.

This is mostly true, except when using a package manager like Nix. To be very brief, Nix installs a package into a directory, and then marks that directory as read-only. This means that plugins cannot, later on, install their .so files into the same data directory of the yosys package. Nix users, therefore, can't simply install a plugin and then invoke a command like yosys -m bluespec -p 'read_bluespec design.bsv' — the location of the plugin file will be in another directory.

To work around this as the Yosys maintainer for Nix, I've added a patch to Yosys that effectively makes yosys instead search a list of directories when looking for a "named" plugin. This patch is very simple. It allows you to add a set of directories to the environment variable NIX_YOSYS_PLUGIN_DIRS separated by :, and Yosys will search them. So invoking

$ export NIX_YOSYS_PLUGIN_DIRS=/d1:/d2:...
$ yosys -m bluespec

will try to load bluespec.so from the following locations, in this order:

YOSYS_DATDIR/plugins/bluespec.so
/d1/bluespec.so
/d2/bluespec.so
...

(Note this environment variable is private and undocumented. It is populated automatically by the Nix infrastructure, so users should be unaware of it. It only exists as a means to an end to make the Yosys UX for Nix users behave similarly to non-Nix users.)

The specifics of this issue aren't really about Nix, though — the above situation could apply to a number of other scenarios i.e. a non-root user using a root-installed yosys, who wants to compile and load their own plugins. So in general, it would be nice to have a more general, proper solution implemented upstream, if it's welcome.

whitequark commented 3 years ago

Sounds perfectly reasonable to me to have something like YOSYS_PLUGIN_DIRS. The main point I'd like to raise is that it should work on Windows and respect its conventions there.

Xiretza commented 3 years ago

This would also be useful for running the testsuite for https://github.com/SymbiFlow/yosys-symbiflow-plugins during packaging. For the implementation I would however suggest searching the directories from the environment variable BEFORE YOSYS_DATDIR, such that it's possible to override already-installed plugins.