Austin Seipp 3d36ea6a05 nextpnr: with GUI support, be sure to set QT_PLUGIN_PATH ... This is to help QT find all the necessary plugin libraries at startup time, otherwise it freaks out when run out of 'nix-env' environment or run directly, e.g. `./result/bin/nextpnr-ice40 --gui`. The reason for this is that none of the traditional paths it looks for are available. The workarounds for this are to otherwise: - Install e.g. into environment.systemPackages (presumably it will then pick up QT libraries in /run/current-system/sw/lib/qt-*) - Install 'qtbase' into your user environment (qt will also try to load dependent libraries out of ~/.nix-profile/lib/qt-*) However, this QT_PLUGIN_PATH wrapping hack is used elsewhere in the tree, presumably to mitigate these (poor) workarounds, especially for non-NixOS users. There seems to be no downside to this. With this, I have been able to run NextPNR's GUI on an Ubuntu 16.04 system using the 'nixGL' hack by simply running the resulting binary from anywhere (though there seems to be some glitching artifacts in the floorplan UI, I suspect this is due to a buggy OpenGL stack rather than any direct problem with NextPNR or the QT libraries themselves). This does not mark the GUI build as non-broken yet, though. That will happen in the future after a bit more testing and splitting nextpnr into separate minimal/GUI attributes. Signed-off-by: Austin Seipp <aseipp@pobox.com>		2019-01-12 15:51:00 -06:00
..
default.nix	nextpnr: with GUI support, be sure to set QT_PLUGIN_PATH	2019-01-12 15:51:00 -06:00