Full explanation of all build options and how it works:

This detailed comment is only for the benefit of easier reviews, giving an at-a-glance view of how it works:

#2980 (comment)

Why it achieves something that would be extremely difficult to replicate on the Wiki:

This handles all of the realistic developer requirements for Prism Launcher: Fast local builds, fast local testing, fast bundle export for manual copying to other test-computers. Without any scope creep turning it into a million-feature wrapper.

It performs the actions in the most universally wanted way, which is appropriate for every normal developer. If any other behavior is desired, someone can easily see what commands are being executed by the script and tweak them manually, and a developer can even add a new -flag which extends BUILD_EXTRA_ARGS with anything else you might desire in the future.

However, any future deviations are unlikely since it handles the entire build process and the manifest in a way that's universal across all Flatpak projects and would work in any Flatpak repository. Any deviations from this exact process would only be needed by people who want to set up their own total-replacement alternatives to Flathub, hosting their own OSTree repos on a custom website -- and people at that level are surely advanced enough to figure out their own commands.

The Wiki PR is extremely inflexible. It forces --user in its examples which does not work whatsoever for typical distros which use System-level Flatpak instead (most of them). Adding the user-level Flathub repo manually with a separate, undocumented command, would make the Wiki's commands "work", barely, but causes incredibly huge bloat on the system, duplicating the massive core runtimes and platforms, graphics drivers, Adwaita, Wayland, and on and on and on at the user-level (instead of letting them remain at the system-level where all the user's other Flatpak installations live)... It also forcibly exports to an OSTree --repo on every build, which wastes many minutes of time for a step which is not necessary at all when merely testing if the build/manifest works. It also cannot install to --system, since it performs the build and install in the same step, and Flatpak does not allow builds to run as root. It also lacks instructions for the typical scenario of making a distributable .flatpak bundle when a developer wants to do testing on other machines in the home.

While you could write a few hundred paragraphs on the Wiki documenting all the variants of every command on the wiki ("do this if you want to do that, but skip that if you want to do that other thing, and don't do that if you don't want that"), which all have to be manually copy-pasted and personalized during builds, it would also be possible to just... save everyone's time and let them wrap the advanced process in a fast way that doesn't do any slow, useless extra work. :)

The existence of this wrapper does not prevent someone from doing anything differently if they truly want to. It just ensures that people don't have to scour a wiki, troubleshoot all the commands, remove all of the suboptimal arguments on the Wiki, such as --repo, remove --user, add --system, manually add sudo (which does not work with flatpak-builder by the way, since compilation refuses to run as root, and sudo flatpak run org.flatpak.Builder is also an illegal command since flatpak run itself cannot run as root either!) and so on... and then realize that it doesn't work... and then read the flatpak documentation, and if they're lucky enough to discover how to install to System from a local repo they'll then have to figure out the correct command args and local repo path format themselves, and then... repeat that entire process every single time they want to build. And finally do the same process when they want to output a .flatpak bundle too. Perhaps copying all of the final commands into some poor text document, forever having to refer to it just to build the project, while not benefitting anybody else in the world who wants to achieve the same thing...

The build-script handles all of the normal developer scenarios for Prism Launcher (and every other Flatpak project) and lowers the barrier to entry for new contributors. It just works -- in a way that a Wiki with rigid commands cannot; unless tons of effort is spent documenting every variation and build combination, and forcing users to manually copy-paste and tweak each individual command of the variant that they desire, which will be above the skill-level of most new contributors. The build-script also does all of this very rapidly, never wasting precious developer time on slow, unnecessary arguments.