hyprwm
Improvements to CMakeLists
This PR brings (as far as i can tell) all of the functionality of the Makefile into CMake, which makes it more automated and friendly to package maintainers, and it follows the typical CMake project convention.
Example build:
$ git clone <Hyprland>
$ cmake -B build -S Hyprland
$ cmake --build build
If desired, can be installed with cmake --install build
~~It should be ready to go as is.~~ Nvm, i found one issue
So, the issue is that while this works fine on its own, for some reason under Arch's package build system I get a build error: make[2]: *** No rule to make target 'wlroots/lib/libwlroots.so.12032', needed by 'Hyprland'. Stop.
Edit: Looks like its caused by the -j option in MAKEFLAGS.
Would be nice if it actually succeeded through the pipelines. If you do make clear and then make release it fails because ninja can't find libwlroots, unsure why
Reverting my commits will not get you anywhere as this will not be merged without .pc installing to /usr/share.
Note to anyone still looking at this: I gave up on having this upstreamed due to the above conversations. But if you still want to continue this you're welcome to fork my fork.
Note to anyone still looking at this: I gave up on having this upstreamed due to the above conversations. But if you still want to continue this you're welcome to fork my fork.
i think the underlying pain point comes from the lack of separation in the dev branches and any packaging fixups. when packaging logic gets woven so deeply into the main development branch 100% of the time package maintainers have their fixups for their own distros mucking up things where it does not have to. debian has spinoff branches for packages for this very reason, instead of mucking about in the dev process of everything they package they periodically rebase spinoff branches for applying small commits for JUST packaging. packaging is a full time job and making the life of the package maintainer is just as important as the people working on the bulk of the meat. when package maintainers and core software developers have to care about divergences from any distro getting in their way something is wrong with how packaging is done. if hyprland could do something more manageable like spinoff branches for nix flakes, RPMs, ebuilds, debs or whatever ever packaging is required i think that this problem would go away and everyone ends up happy as a result. i would personally like to feel out how people in hyprland feel about that as i think that everyone who wants to contribute but doesnt is influenced by the build system being so convoluted by being intertwined with packaging right now.
Note to anyone still looking at this: I gave up on having this upstreamed due to the above conversations. But if you still want to continue this you're welcome to fork my fork.
i think the underlying pain point comes from the lack of separation in the dev branches and any packaging fixups. when packaging logic gets woven so deeply into the main development branch 100% of the time package maintainers have their fixups for their own distros mucking up things where it does not have to. debian has spinoff branches for packages for this very reason, instead of mucking about in the dev process of everything they package they periodically rebase spinoff branches for applying small commits for JUST packaging. packaging is a full time job and making the life of the package maintainer is just as important as the people working on the bulk of the meat. when package maintainers and core software developers have to care about divergences from any distro getting in their way something is wrong with how packaging is done. if hyprland could do something more manageable like spinoff branches for nix flakes, RPMs, ebuilds, debs or whatever ever packaging is required i think that this problem would go away and everyone ends up happy as a result. i would personally like to feel out how people in hyprland feel about that as i think that everyone who wants to contribute but doesnt is influenced by the build system being so convoluted by being intertwined with packaging right now.
That's what I tried to do, the upstream shouldn't care about the target distribution at all, and it should be left to the packagers, but they insisted on supporting distributions when installing to system with cmake, which is just moronic (and makes downstream packaging more difficult)
Note to anyone still looking at this: I gave up on having this upstreamed due to the above conversations. But if you still want to continue this you're welcome to fork my fork.
i think the underlying pain point comes from the lack of separation in the dev branches and any packaging fixups. when packaging logic gets woven so deeply into the main development branch 100% of the time package maintainers have their fixups for their own distros mucking up things where it does not have to. debian has spinoff branches for packages for this very reason, instead of mucking about in the dev process of everything they package they periodically rebase spinoff branches for applying small commits for JUST packaging. packaging is a full time job and making the life of the package maintainer is just as important as the people working on the bulk of the meat. when package maintainers and core software developers have to care about divergences from any distro getting in their way something is wrong with how packaging is done. if hyprland could do something more manageable like spinoff branches for nix flakes, RPMs, ebuilds, debs or whatever ever packaging is required i think that this problem would go away and everyone ends up happy as a result. i would personally like to feel out how people in hyprland feel about that as i think that everyone who wants to contribute but doesnt is influenced by the build system being so convoluted by being intertwined with packaging right now.
That's what I tried to do, the upstream shouldn't care about the target distribution at all, and it should be left to the packagers, but they insisted on supporting distributions when installing to system with cmake, which is just moronic (and makes downstream packaging more difficult)
i personally would like to reduce the friction on this somehow so hyprland can eventually be packaged in debian.