Meson run_target support
In meson, I can define a run_target
, which is a target that doesn't generate anything executable but does something useful (i.e. "runs the program", when that means something different than launching a built executable). I'd like to be able to make Builder's run button execute a run_target
in meson.
My use case for Builder is quite specific: I'm building a few OS-level components (GUI and/or otherwise), and most of them need some "magic" before/during/after running the actual binary to get them to run right. Here's a few examples:
- my DE's panel needs to first ask systemd to stop running the system's built-in copy of itself, or else they'll conflict over the dbus name and placement by the compositor
- my DE's various dialogs (polkit, geoclue, gnome-session, etc) have a similar story as the panel
- my custom gnome-software plugin can't run directly, but can run through a little helper script that sets up an appropriate environment for gnome-software and then executes it
- my OS update daemon shouldn't be run directly; instead I have a script that generates a fake OS installation and starts up the daemon with the appropriate environment so that I can completely test it (generate fake system updates, install them, etc) without damaging my OS installation.
- my initial-setup/installer program has a "mock" mode, where I need to set an environment variable to bypass the autodetection code and force it into one of its modes (installer or initial setup) and disable destructive actions. Without this env-var set, the setup program will fail to launch because it detects that it's running in an invalid environment: an installed and fully set-up OS.
My workflow with these right now is rather ugly:
- I press Run to build & install the code, then I click out of the "application output" tab (which usually contains errors because the program was not run in a valid environment) and into the "terminal" tab, then I run some kind of script to actually run the program with the correct environment
- I often have to run a script before I press Run in Builder to stop system services as appropriate. Then I can work on my components, and finally I have to run another script before I close out of Builder to restart the system's services
- For my initial-setup program, I have to go to the Build Preferences page and set the right environment variables manually every time I launch Builder.
All of these use-cases and issues can be implemented/solved as run_targets in meson. Really all that needs to happen is GNOME Builder should build & install the package, and then instead of running the built executable it could just run a meson run_target, which will run a small script that correctly sets up the environment & runs the compiled executable. From GNOME Builder's perspective, running these should be no different to just running an executable.
Let me go use-case-by-use-case and list how a run_target could help:
- panel & dialogs: the run_target would be a script that asks the system to stop the appropriate services and then runs the compiled binary. Once the user presses the "stop running" button, the script could catch the signal, kill its child process, and then ask the system to restart the appropriate services
- gnome-software plugin: the run_target would set up the correct environment for gnome-software (kill the already-running copy, set up env-vars to load my built plugin, enable debug output), then
exec gnome-software
. The "stop running" button would at that point just send the kill signal to gnome-software directly - OS update daemon: just run the test script as the program. The script will work exactly like it does now, it'll just also happen to integrate with Builder
- Initial setup: I'd have a couple run_targets, one for each mode the initial-setup program can run in (just sets the environment variable & exec's the compiled program). Then instead of having to go and manually edit environment variables, I can just click on the "Build targets" dropdown and run the appropriate target