-
-
Notifications
You must be signed in to change notification settings - Fork 988
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
Remove dependency on glaze #9067
base: main
Are you sure you want to change the base?
Conversation
I got a segfault building with this PR
Gentoo doesn't natively package glaze and it's a pain having to build it out of tree. I don't use plugins either so I'm not of much use either sorry |
@gksudolol not completely sure what's up with that segfault, I was able to build it (with the latest hyprutils and aquamarine) and it's running fine for me now. (also, I don't use plugins, and hyprpm doesn't seem to work for me)... But this should work fine in theory. |
it might have been my end, i'll build again and test out hyprpm |
plugins don't seem to work for me with or without this PR |
I haven't gotten hyprpm to work correctly either, but I can load a plugin if
So, to be honest, I wouldn't mind a build flavor without hyprpm... that whole idea (of having code that downloads and compiles plugins) is kind of against how I want [plugins] to work from a distro perspective. |
My lack of hyprpm knowledge would have never figured to make and load manually haha Perhaps a build option for hyprpm would be the best use case? Then figure whether to pull out glaze dep, or keep |
Using an advanced JSON library for string parsing was overkill, and limited compatibility as glaze compiles on fewer systems than all of hypr*
Sure, can be done. |
Merged. |
Describe your PR, what does it fix/add?
Attempt to remove dependency on glaze by making
hyprctl plugins list
output a 'terse' format.see #8812 #8899
I was originally trying to compile glaze on alpine, but it had issues (with _Float128 and
std::to_chars
andstd::from_chars
), which I think belong to libc++ when compiled on musl... Given that glaze was only added to simplify some string parsing, I think it would be much less effort for me to just not use glaze in hyprland than to fix issues compiling glaze.Is there anything you want to mention? (unchecked code, possible bugs, found problems, breaking compatibility, etc.)
Need to test this more
Is it ready for merging, or does it need work?
I've tested this... but not fully
Also needs documentation updates