Update README, update Makefile

This commit is contained in:
Stanisław Zagórowski 2023-04-17 18:43:04 +02:00
parent 27fe82f602
commit 70e05e5068
2 changed files with 18 additions and 11 deletions

View File

@ -26,6 +26,7 @@ OBJECT_DIR=obj
# Compiler flags # Compiler flags
COMPILE_FLAGS=-g -fPIC --no-gnu-unique -std=c++23 COMPILE_FLAGS=-g -fPIC --no-gnu-unique -std=c++23
COMPILE_FLAGS+=-fdiagnostics-color=always
COMPILE_FLAGS+=-I "/usr/include/pixman-1" COMPILE_FLAGS+=-I "/usr/include/pixman-1"
COMPILE_FLAGS+=-I "/usr/include/libdrm" COMPILE_FLAGS+=-I "/usr/include/libdrm"
COMPILE_FLAGS+=-I "${HYPRLAND_HEADERS}" COMPILE_FLAGS+=-I "${HYPRLAND_HEADERS}"

View File

@ -21,6 +21,8 @@ at the top of the repository file view.
For a code editor, I recommend VS Code or Neovim, but anything that can use Clangd will work For a code editor, I recommend VS Code or Neovim, but anything that can use Clangd will work
If you use Clangd, `make clangd` will generate a simple `compile_flags.txt` file with the proper If you use Clangd, `make clangd` will generate a simple `compile_flags.txt` file with the proper
include paths and flags, which will make Clangd recognize the includes etc. include paths and flags, which will make Clangd recognize the includes etc.
Alternatively, use [bear](https://github.com/rizsotto/Bear) to generate `compile_commands.json`
which is a bit more granular.
> **Warning**: Compiling the plugin should still be done using GCC 12+. Clang does not properly > **Warning**: Compiling the plugin should still be done using GCC 12+. Clang does not properly
> build Hyprland, and is very fussy about the hook system. You will most likely encounter errors > build Hyprland, and is very fussy about the hook system. You will most likely encounter errors
@ -35,24 +37,23 @@ that.
When building your own plugins for testing, you will need to manually define it using When building your own plugins for testing, you will need to manually define it using
`export HYPRLAND_HEADERS=(PATH_TO_HYPRLAND_SOURCE_ROOT)` before running `make` commands. You `export HYPRLAND_HEADERS=(PATH_TO_HYPRLAND_SOURCE_ROOT)` before running `make` commands. You
can use a local path if you keep `Hyprland` source anyway, but I'd definitely recomment using can use a local path if you keep `Hyprland` source anyway, but I'd definitely recommend using
`hyprload`. If you use your local source different from the `hyprload` one, make sure to `hyprload`. If you use your local source different from the `hyprload` one, make sure to
run `make pluginenv` in the Hyprland folder. run `make pluginenv` in the Hyprland folder.
And here, excuse me, but I will go on a tangent about why `hyprload` is great:
#### Hyprload, and why it's useful for plugin development #### Hyprload, and why it's useful for plugin development
If you use `hyprload`, it will keep a copy of Hyprland source code up to date with the Hyprland If you use `hyprload`, handing `HYPRLOAD_HEADERS` becomes a bit easier and more reliable.
version you're running in `$HOME/.local/share/hyprload/hyprland`, and you can use that as your By design it keeps a copy of Hyprland source code up to date with the Hyprland version you're
running in `$HOME/.local/share/hyprload/hyprland`, and you can use that as your
`HYPRLAND_HEADERS` path. `HYPRLAND_HEADERS` path.
When installing your plugin on other people's computers, `hyprload` will automatically define When users install your plugin via `hyprload`, it will automatically define `HYPRLAND_HEADERS`
`HYPRLAND_HEADERS` to that path to ensure maximum compatibility. to that path to ensure maximum compatibility.
When developing plugins and frequently changing them, the `make install` command will When developing plugins and frequently changing them, the `make install` command will
automatically place your plugin build in the directory `hyprload` automatically loads. You can automatically place your plugin build in the directory `hyprload` automatically loads. You can
reload plugins when testing using the `hyprload,reload` dispatcher (bind it in your reload plugins when testing using the `hyprload reload` dispatcher (bind it in your
`hyprland.conf` `hyprland.conf`, or execute via `hyprctl dispatch hyprload reload`)
#### Making it Your Own #### Making it Your Own
To change your plugin name, version, and author (that's you!) there are 3 variables that need To change your plugin name, version, and author (that's you!) there are 3 variables that need
@ -70,16 +71,21 @@ After making sure you have defined `HYPRLAND_HEADERS` (you might need to do this
you open a new terminal* if you don't put it in your `.bashrc` or `.zshrc` or whatever), the you open a new terminal* if you don't put it in your `.bashrc` or `.zshrc` or whatever), the
steps to build are simple steps to build are simple
### Manual way of doing things ### Manually
- `make`: This will build the `PLUGIN_NAME.so` file. - `make`: This will build the `PLUGIN_NAME.so` file.
- `hyprctl plugin unload $PWD/PLUGIN_NAME.so`: If you have an old version loaded, unload it - `hyprctl plugin unload $PWD/PLUGIN_NAME.so`: If you have an old version loaded, unload it
- `hyprctl plugin load $PWD/PLUGIN_NAME.so`: Load the plugin - `hyprctl plugin load $PWD/PLUGIN_NAME.so`: Load the plugin
### The `hyprload` way Do note that if you only load/unload from the same path, Hyprland can ignore your changes.
### Using `hyprload`
This works rather well in nested Hyprland sessions, since `hyprload` keeps sessions separate. This works rather well in nested Hyprland sessions, since `hyprload` keeps sessions separate.
- `make install`: This will build and copy the plugin to the `hyprload` plugin directory. - `make install`: This will build and copy the plugin to the `hyprload` plugin directory.
- Reload `hyprload` for the changes to take effect - Reload `hyprload` for the changes to take effect
This doesn't have the issue of ignoring changes, because of how `hyprload` handles its loaded
plugins.
### Nested Hyprland ### Nested Hyprland
Developing a plugin may be tough. You might crash Hyprland a couple times. For this reason, Developing a plugin may be tough. You might crash Hyprland a couple times. For this reason,
it's a good idea to develop them in a nested Hyprland session. If you run `Hyprland` from an it's a good idea to develop them in a nested Hyprland session. If you run `Hyprland` from an