Plugin header overhaul 2: fixes (Electric boogaloo)

[vaxerski]

Fixes for the plugin overhaul:

• make pluginenv makes sense
• wlroots headers install to $PREFIX/include/hyprland/wlroots (./subprojects/wlroots/include -> $PREFIX/include/hyprland/wlroots)

Todo:

• Meson

[vaxerski]

cc @horriblename @eli-schwartz @fufexan

cmake / makefile side is done, we just pretty much need meson to copy wlroots/include/* to $PREFIX/include/hyprland/wlroots

Ref:

Hyprland/Makefile

Line 59 in 7138de7

cd subprojects/wlroots/include && find . -name '*.h*' -exec cp --parents '{}' ${PREFIX}/include/hyprland/wlroots ';' && cd ../../..

[eli-schwartz]

wlroots installs these files here: https://gitlab.freedesktop.org/wlroots/wlroots/-/blob/master/include/meson.build#L27

wlroots wants them in /usr/include 🤷

Either start supporting the system wlroots or idk, fork and patch it or something. I strongly encourage supporting the system wlroots, but I'm given to understand that option has been vehemently nixed...

[vaxerski]

We don't install those headers AFAIK? We absolutely shouldn't and cmake doesn't.

System wlroots -> /usr/include
Hyprland wlroots -> $PREFIX/include/hyprland/wlroots

I mean, we can always just execute a shell command with meson as a last resort, if meson really can't do that, I assume?

They are not for wlroots anyways. They're for plugins. If a plugin includes a hyprland header, it should source wlroots headers from the hyprland headers.

[droc12345]

Using system wlroots only makes sense, if there is only one wlroots compositor using it.
As the eco-system stands now, 3 different compositors pretty much need 3 different versions of wlroots.

By default if you don't tell meson to "install --skip-subprojects" then it tries to put the subproject files in /usr/include/wlroots for example.

I'm not sure about changing the default install dir in a subproject

[vaxerski]

IDK, but this has to be solved. We can skip meson for now and just request users to run make pluginenv as usual if they installed via meson, but ideally, I'd like to keep parity between build systems.

As usual, my decision ages ago to allow meson comes back to bite me in the ass.

If meson does not support this, we can always nuclearly some_execute_command "sed ..." like we already do with cmake for a proper sover.

On that note, how does meson handle the wlroots .so? Wouldn't "no modifications" make it overwrite system wlroots?

[eli-schwartz]

If meson does not support this, we can always nuclearly some_execute_command "sed ..." like we already do with cmake for a proper sover.

You can indeed use meson to execute run_command('sed', '-i', 'some-sed-command', 'subprojects/wlroots/include/meson.build') and whatever else you'd like to do.

Or even use an https://github.com/hyprwm/wlroots/ fork with some patches applied, and then not have to mess with sed for either cmake or meson.

[vaxerski]

Or even use an https://github.com/hyprwm/wlroots/ fork with some patches applied, and then not have to mess with sed for either cmake or meson.

I'll pass, too much hassle + will make people want me to apply patches myself, which I hella don't want to do.

You can indeed use meson to execute run_command('sed', '-i', 'some-sed-command', 'subprojects/wlroots/include/meson.build') and whatever else you'd like to do.

If that's the only way to accomplish installing wlroots headers to a different location with meson, let it be. I'll leave the decision to @fufexan

[vaxerski]

I'll merge the cmake + makefile part for now and edit the wiki so that we can get plugins to work again, and the meson stuff I'll leave as @fufexan 's job

[fufexan]

I have come up with a relatively small change to the wlroots include/meson.build file that installs properly. However, I don't know how to best approach patching the file. I've read about wraps, but it says you shouldn't manually write them.
@eli-schwartz do you know if I could use those or something else?
Here's the patch

diff --git a/include/meson.build b/include/meson.build
index e6698003..687786b8 100644
--- a/include/meson.build
+++ b/include/meson.build
@@ -1,4 +1,5 @@
-subdir('wlr')
+run_command('ln', '-s', join_paths(meson.project_source_root(), 'include', 'wlr'), join_paths(meson.project_source_root(), 'include', 'wlroots'), check: true)
+subdir('wlroots')
 
 exclude_files = ['meson.build', 'config.h.in', 'version.h.in']
 if not features.get('drm-backend')
@@ -24,8 +25,8 @@ if not features.get('session')
 	exclude_files += 'backend/session.h'
 endif
 
-install_subdir('wlr',
-	install_dir: get_option('includedir'),
+install_subdir('wlroots',
+	install_dir: join_paths(get_option('includedir'), 'hyprland'),
 	exclude_files: exclude_files,
 )

[eli-schwartz]

All wraps start off written by hand :P some of them are then shared publicly so that other people can take advantage of existing work rather than reinventing it.

[fufexan]

@eli-schwartz I've tried making a wrap file but it does not seem to be doing anything. Am I doing it wrong, do I need to fetch the submodule through the wrap file?
The PR with the relevant changes is #2287.

[eli-schwartz]

• diff_files are stored in subprojects/packagefiles/
• meson won't apply it on every single build, that's not idempotent. It will apply it either when meson sees that the subproject doesn't exist yet, and downloads it for you, OR when running the meson subprojects update tool. In the latter case it actually stashes modifications etc. and otherwise figures out of it can safely re-patch on top of an existing applied patch.