ghdl / ghdl-yosys-plugin

VHDL synthesis (based on ghdl)
GNU General Public License v3.0
295 stars 32 forks source link

Debian patches regarding DESTDIR and plugin install dir #166

Closed DanielG closed 2 years ago

DanielG commented 2 years ago

Support installing into $DESTDIR

This makes packaging easier for distributions as installation is usually staged in a temporary directory when building intallable packages.


Allow overriding plugin installation directory

Currently we install the plugin into /usr/share since this is where yosys loads from, however this violates the FHS as only architecture-independent data is supposed to be installed in share.

Until this is reolved properly at least allow overriding the plugin installation directory explicitly using make variables on the command line.

See YosysHQ/yosys#3151

DanielG commented 2 years ago

No permutations are tried as far as I could see from the source. Only the relative filename and then in /usr/share/yosys/plugins. See https://github.com/YosysHQ/yosys/blob/master/passes/cmds/plugin.cc#L77

Indeed passing a full filename to -m would "solve" it, but I want people not to have to write Debian specific Makefiles so that obviously sucks. Putting the ghdl plugin in /usr/lib isn't really fesible either due to distribution policy surrounding library versioning and SONAME. Even if that isn't a blocker a library just called "ghdl.so" is obviously a no-go in a global namespace :(

umarcor commented 2 years ago

@DanielG I believe we are open to changing the library name, and to making it versioned, if that helps distribution. That's something we did in the main repo during the last months (libghdl and libghw).

Changing the name to e.g. libghdlyosys or libyosysghdl would be easy. The problem is attaching the versioning. ghdl-yosys-plugin is very tightly dependent on both GHDL and Yosys. It does not require specific versions of them, but the windows are pretty narrow. So, how can we deal with deciding when to change the plugin library version?

DanielG commented 2 years ago

Thinking about it bumping the SONAME version probably wouldn't have to happen too often since the API towards yosys is fairly fixed (I haven't looked at the details yet, just guessing). In general it is quite hard to automatically detect when SONAME should be bumped since it can depend on the behavior of the exported symbols, not just the names of them.

Honestly I feel this is too much to expect from a small project that's not super familiar with the concerns there. IMO things are fine how they are just the precise location of the plugins needs to change and perhaps having an environment variable to let users override/append to the load path isn't a bad idea too (there's already a yosys issue for that too).