nixpkgs/pkgs/development/compilers/yosys/setup-hook.sh

addYosysPluginPath() {
  addToSearchPath NIX_YOSYS_PLUGIN_DIRS "$1/share/yosys/plugins"
}

addEnvHooks "$targetOffset" addYosysPluginPath
yosys: enable loading "out of band" plugins By default, when yosys looks for plugins with the `-m` flag or `plugin` command, it always looks in `YOSYS_PREFIX/share/yosys/plugins` for a `.so` file, and loads that. By design, this is intended to be a single, global, mutable location such as `/usr/share/yosys/...` on disk, and plugins are supposed to install their `.so` files here after yosys is installed, and they all coexist together. Obviously, this won't work for us, but users might expect these plugins to still work. More importantly, they won't want to add special cases to their build systems. Instead, to allow Nix users to use yosys plugins with the same UX (e.g. natively call `plugin bluespec` or `-m ghdl`), we add a patch to yosys that allows it to search a new `NIX_YOSYS_PLUGIN_DIRS` search path environment variable. In tandem, we add a setup hook that adds to this search path if a package has a `$out/share/yosys/plugins` directory. Thus, it's enough to just include `yosys`, and any package that has a yosys plugin in `$out/share/yosys/plugins`, and you can load it with `-m` or the `plugin` command. We could use a style like the haskellPackages set, where the set of packages are "encased" in a lambda, and we pass packages that are compatible with that version of the compiler: haskell.packages.ghc8102.ghcWithPackages (p: with p; [ ... ]) but, realistically, there will probably only ever be one version of yosys and one set of compatible plugins, so this seems overdone. Signed-off-by: Austin Seipp <aseipp@pobox.com> 2021-01-15 06:52:23 +01:00			`addYosysPluginPath() {`
			`addToSearchPath NIX_YOSYS_PLUGIN_DIRS "$1/share/yosys/plugins"`
			`}`

			`addEnvHooks "$targetOffset" addYosysPluginPath`