Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

hyprpm shared lib path #6068

Open
xorander00 opened this issue May 15, 2024 · 0 comments
Open

hyprpm shared lib path #6068

xorander00 opened this issue May 15, 2024 · 0 comments
Labels
enhancement New feature or request

Comments

@xorander00
Copy link

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 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).

@xorander00 xorander00 added the enhancement New feature or request label May 15, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant