You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
(I originally started writing this as a comment on #5997 but decided to create a new issue since the potential solution would be a distinct enhancement)
User-specified build flags would be nice, though a lot of that is already supported via standard environment variables (e.g. CFLAGS, CXXFLAGS, LDFLAGS, etc). However, does hyprpm pass the user environment as-is to spawned processes or does it selectively pass environment variables? I think I remember trying to set CXXFLAGS+LDFLAGS and the build commands seemed to not get them, though I might be mistaken (it was a while ago).
What would be nicer though would be the ability to specify patches to apply to a plugin repo before building. I'm running FreeBSD where LLVM is the default compiler. A lot of plugins use GNU-specific flags (e.g. -fno-gnu-unique) or have GNU-make specific Makefiles and don't respect variables like MAKE or MAKE_CMD (to use gmake instead). Some will make path assumptions like /lib instead of /usr/local/lib. Some plugins don't respect existing environment variables (e.g. CXXFLAGS := ... instead of CXXFLAGS ?= ...), or set make variables so that user-specified variables are prefixed instead of suffixed (e.g. CXXFLAGS := $(CXXFLAGS) -some-toggle-flag-that-clang-freaks-out-about instead of CXXFLAGS := -some-toggle-flag-that-clang-freaks-out-about $(CXXFLAGS), where with the latter I can set CXXFLAGS=-no-toggle-flag-that-clang-freaks-out-about to turn it off).
Currently, I'm manually cloning, patching, & compiling plugin shared libs and putting them in ~/.local/share/hyprpm/, then enabling them. It would be nice to be able to do something like hyprpm add --patch ~/.config/hypr/patches/plugin-freebsd.patch https://github.com/org/plugin.
Though an alternative, and probably better approach, would be to point hyprpm to an alternative path where plugin .so files are located. Then I could create FreeBSD ports (the package management system) for hyprland plugins which would take care of fetching sources, applying patches, building .so files, and putting them in the standard path (e.g. /usr/local/lib/hyprpm/hyprscroller.so).
The text was updated successfully, but these errors were encountered:
Description
(I originally started writing this as a comment on #5997 but decided to create a new issue since the potential solution would be a distinct enhancement)
User-specified build flags would be nice, though a lot of that is already supported via standard environment variables (e.g. CFLAGS, CXXFLAGS, LDFLAGS, etc). However, does hyprpm pass the user environment as-is to spawned processes or does it selectively pass environment variables? I think I remember trying to set CXXFLAGS+LDFLAGS and the build commands seemed to not get them, though I might be mistaken (it was a while ago).
What would be nicer though would be the ability to specify patches to apply to a plugin repo before building. I'm running FreeBSD where LLVM is the default compiler. A lot of plugins use GNU-specific flags (e.g. -fno-gnu-unique) or have GNU-make specific Makefiles and don't respect variables like MAKE or MAKE_CMD (to use gmake instead). Some will make path assumptions like /lib instead of /usr/local/lib. Some plugins don't respect existing environment variables (e.g.
CXXFLAGS := ...
instead ofCXXFLAGS ?= ...
), or set make variables so that user-specified variables are prefixed instead of suffixed (e.g.CXXFLAGS := $(CXXFLAGS) -some-toggle-flag-that-clang-freaks-out-about
instead ofCXXFLAGS := -some-toggle-flag-that-clang-freaks-out-about $(CXXFLAGS)
, where with the latter I can setCXXFLAGS=-no-toggle-flag-that-clang-freaks-out-about
to turn it off).Currently, I'm manually cloning, patching, & compiling plugin shared libs and putting them in ~/.local/share/hyprpm/, then enabling them. It would be nice to be able to do something like
hyprpm add --patch ~/.config/hypr/patches/plugin-freebsd.patch https://github.com/org/plugin
.Though an alternative, and probably better approach, would be to point hyprpm to an alternative path where plugin .so files are located. Then I could create FreeBSD ports (the package management system) for hyprland plugins which would take care of fetching sources, applying patches, building .so files, and putting them in the standard path (e.g. /usr/local/lib/hyprpm/hyprscroller.so).
The text was updated successfully, but these errors were encountered: