forked from obsproject/obs-plugintemplate
-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
Showing
1 changed file
with
147 additions
and
34 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -2,58 +2,171 @@ | |
|
|
||
| ## Introduction | ||
|
|
||
| This plugin is meant to make it easy to quickstart development of new OBS plugins. It includes: | ||
| The plugin template is meant to be used as a starting point for OBS Studio plugin development. It includes: | ||
|
|
||
| - The CMake project file | ||
| - Boilerplate plugin source code | ||
| - GitHub Actions workflows and repository actions | ||
| - Build scripts for Windows, macOS, and Linux | ||
| * Boilerplate plugin source code | ||
| * A CMake project file | ||
| * GitHub Actions workflows and repository actions | ||
|
|
||
| ## Set Up | ||
|
|
||
| The plugin project is set up using the included `buildspec.json` file. The following fields should be customized for an actual plugin: | ||
|
|
||
| * `name`: The plugin name | ||
| * `version`: The plugin version | ||
| * `author`: Actual name or nickname of the plugin's author | ||
| * `website`: URL of a website associated with the plugin | ||
| * `email`: Contact email address associated with the plugin | ||
| * `uuids` | ||
| * `macosPackage`: Unique (**!**) identifier for the macOS plugin package | ||
| * `macosInstaller`: Unique (**!**) identifier for the macOS plugin installer | ||
| * `windowsApp`: Unique (**!**) identifier for the Windows plugin installer | ||
|
|
||
| ## Configuring | ||
| These values are read and processed automatically by the CMake build scripts, so no further adjustments in other files are needed. | ||
|
|
||
| Open `buildspec.json` and change the name and version of the plugin accordingly. This is also where the obs-studio version as well as the pre-built dependencies for Windows and macOS are defined. Use a release version (with associated checksums) from a recent [obs-deps release](https://github.com/obsproject/obs-deps/releases). | ||
| ### Platform Configuration | ||
|
|
||
| Next, open `CMakeLists.txt` and edit the following lines at the beginning: | ||
| Platform-specific settings are set up in the `platformConfig` section of the buildspec file: | ||
|
|
||
| ```cmake | ||
| project(obs-plugintemplate VERSION 1.0.0) | ||
| * `bundleId`: macOS bundle identifier for the plugin. Should be unique and follow reverse domain name notation. | ||
|
|
||
| set(PLUGIN_AUTHOR "Your Name Here") | ||
| ### Set Up Build Dependencies | ||
|
|
||
| set(LINUX_MAINTAINER_EMAIL "[email protected]") | ||
| ``` | ||
| Just like OBS Studio itself, plugins need to be built using dependencies available either via the `obs-deps` repository (Windows and macOS) or via a distribution's package system (Linux). | ||
|
|
||
| The build scripts (contained in the `.github/scripts` directory) will update the `project` line automatically based on values from the `buildspec.json` file. If the scripts are not used, these changes need to be done manually. | ||
| #### Choose An OBS Studio Version | ||
|
|
||
| By default the plugin template specifies the most current official OBS Studio version in the `buildspec.json` file, which makes most sense for plugins at the start of development. As far as updating the targeted OBS Studio version is concerned, a few things need to be considered: | ||
|
|
||
| * Plugins targeting _older_ versions of OBS Studio should _generally_ also work in newer versions, with the exception of breaking changes to specific APIs which would also be explicitly called out in release notes | ||
| * Plugins targeting the _latest_ version of OBS Studio might not work in older versions because the internal data structures used by `libobs` might not be compatible | ||
| * Users are encouraged to always update to the most recent version of OBS Studio available within a reasonable time after release - plugin authors have to choose for themselves if they'd rather keep up with OBS Studio releases or stay with an older version as their baseline (which might of course preclude the plugin from using functionality introduced in a newer version) | ||
|
|
||
| On Linux, the version used for development might be decided by the specific version available via a distribution's package management system, so OBS Studio compatibility for plugins might be determined by those versions instead. | ||
|
|
||
| #### Windows and macOS | ||
|
|
||
| Windows and macOS dependency downloads are configured in the `buildspec.json` file: | ||
|
|
||
| * `dependencies`: | ||
| * `obs-studio`: Version of OBS Studio to build plugin with (needed for `libobs` and `obs-frontend-api`) | ||
| * `prebuilt`: Prebuilt OBS Studio dependencies | ||
| * `qt6`: Prebuilt version of Qt6 as used by OBS Studio | ||
| * `tools`: Contains additional build tools used by CI | ||
|
|
||
| The values should be kept in sync with OBS Studio releases and the `buildspec.json` file in use by the main project to ensure that the plugin is developed and built in sync with its target environment. | ||
|
|
||
| To update a dependency, change the `version` and associated `hashes` entries to match the new version. The used hash algorithm is `sha256`. | ||
|
|
||
| #### Linux | ||
|
|
||
| Linux dependencies need to be resolved using the package management tools appropriate for the local distribution. As an example, building on Ubuntu requires the following packages to be installed: | ||
|
|
||
| * Build System Dependencies: | ||
| * `cmake` | ||
| * `ninja-build` | ||
| * `pkg-config` | ||
| * Build Dependencies: | ||
| * `build-essential` | ||
| * `libobs-dev` | ||
| * Qt6 Dependencies: | ||
| * `qt6-base-dev` | ||
| * `libqt6svg6-dev` | ||
| * `qt6-base-private-dev` | ||
|
|
||
| ## Build System Configuration | ||
|
|
||
| To create a build configuration, `cmake` needs to be installed on the system. The plugin template supports CMake presets using the `CMakePresets.json` file and ships with default presets: | ||
|
|
||
| * `macos` | ||
| * Universal architecture (supports Intel-based CPUs as Apple Silicon) | ||
| * Defaults to Qt version `6` | ||
| * Defaults to macOS deployment target `11.0` | ||
| * `macos-ci` | ||
| * Inherits from `macos` | ||
| * Enables compile warnings as error | ||
| * `windows-x64` | ||
| * Windows 64-bit architecture | ||
| * Defaults to Qt version `6` | ||
| * Defaults to Visual Studio 17 2022 | ||
| * Defaults to Windows SDK version `10.0.18363.657` | ||
| * `windows-ci-x64` | ||
| * Inherits from `windows-x64` | ||
| * Enables compile warnings as error | ||
| * `linux-x86_64` | ||
| * Linux x86_64 architecture | ||
| * Defaults to Qt version `6` | ||
| * Defaults to Ninja as build tool | ||
| * Defaults to `RelWithDebInfo` build configuration | ||
| * `linux-ci-x86_64` | ||
| * Inherits from `linux-x86_64` | ||
| * Enables compile warnings as error | ||
| * `linux-aarch64` | ||
| * Provided as an experimental preview feature | ||
| * Linux aarch64 (ARM64) architecture | ||
| * Defaults to Qt version `6` | ||
| * Defaults to Ninja as build tool | ||
| * Defaults to `RelWithDebInfo` build configuration | ||
| * `linux-ci-aarch64` | ||
| * Inherits from `linux-aarch64` | ||
| * Enables compile warnings as error | ||
|
|
||
| Presets can be either specified on the command line (`cmake --preset <PRESET>`) or via the associated select field in the CMake Windows GUI. Only presets appropriate for the current build host are available for selection. | ||
|
|
||
| Additional build system options are available to developers: | ||
|
|
||
| * `ENABLE_CCACHE`: Enables support for compilation speed-ups via ccache (enabled by default on macOS and Linux) | ||
| * `ENABLE_FRONTEND_API`: Adds OBS Frontend API support for interactions with OBS Studio frontend functionality (disabled by default) | ||
| * `ENABLE_QT`: Adds Qt6 support for custom user interface elements (disabled by default) | ||
| * `CODESIGN_IDENTITY`: Name of the Apple Developer certificate that should be used for code signing | ||
| * `CODESIGN_TEAM`: Apple Developer team ID that should be used for code signing | ||
|
|
||
| ## GitHub Actions & CI | ||
|
|
||
| The scripts contained in `github/scripts` can be used to build and package the plugin and take care of setting up obs-studio as well as its own dependencies. A default workflow for GitHub Actions is also provided and will use these scripts. | ||
| Default GitHub Actions workflows are available for the following repository actions: | ||
|
|
||
| * `push`: Run for commits or tags pushed to `master` or `main` branches. | ||
| * `pr-pull`: Run when a Pull Request has been pushed or synchronized. | ||
| * `dispatch`: Run when triggered by the workflow dispatch in GitHub's user interface. | ||
| * `build-project`: Builds the actual project and is triggered by other workflows. | ||
| * `check-format`: Checks CMake and plugin source code formatting and is triggered by other workflows. | ||
|
|
||
| The workflows make use of GitHub repository actions (contained in `.github/actions`) and build scripts (contained in `.github/scripts`) which are not needed for local development, but might need to be adjusted if additional/different steps are required to build the plugin. | ||
|
|
||
| ### Retrieving build artifacts | ||
|
|
||
| Each build produces installers and packages that you can use for testing and releases. These artifacts can be found on the action result page via the "Actions" tab in your GitHub repository. | ||
| Successful builds on GitHub Actions will produce build artifacts that can be downloaded for testing. These artifacts are commonly simple archives and will not contain package installers or installation programs. | ||
|
|
||
| ### Building a Release | ||
|
|
||
| To create a release, an appropriately named tag needs to be pushed to the `main`/`master` branch using semantic versioning (e.g., `12.3.4`, `23.4.5-beta2`). A draft release will be created on the associated repository with generated installer packages or installation programs attached as release artifacts. | ||
|
|
||
| ## Signing and Notarizing on macOS | ||
|
|
||
| Plugins released for macOS should be codesigned and notarized with a valid Apple Developer ID for best user experience. To set this up, the private and personal key of a **paid Apple Developer ID** need to be downloaded from the Apple Developer portal: | ||
|
|
||
| #### Building a Release | ||
| * On your Apple Developer dashboard, go to "Certificates, IDs & Profiles" and create two signing certificates: | ||
| * One of the "Developer ID Application" type. It will be used to sign the plugin's binaries | ||
| * One of the "Developer ID Installer" type. It will be used to sign the plugin's installer | ||
|
|
||
| Simply create and push a tag and GitHub Actions will run the pipeline in Release Mode. This mode uses the tag as its version number instead of the git ref in normal mode. | ||
| The developer certificate will usually carry a name similar in form to | ||
|
|
||
| ### Packaging on Linux | ||
| `Developer ID Application: <FIRSTNAME> <LASTNAME> (<LETTERS_AND_NUMBERS>)` | ||
|
|
||
| The install step results in different directory structures depending on the value of `LINUX_PORTABLE` - "OFF" will organize outputs to be placed in the system root, such as `/usr/`, and "ON" will organize outputs for portable installations in the user's home directory. If you are packaging for a Linux distribution, you probably want to set `-DLINUX_PORTABLE=OFF`. | ||
| This entire string should be specified as `CODESIGN_IDENTITY`, the `LETTERS_AND_NUMBERS` part as `CODESIGN_TEAM` to CMake to set up codesigning properly. | ||
|
|
||
| ### Signing and Notarizing on macOS | ||
| ### GitHub Actions Set Up | ||
|
|
||
| On macOS, Release Mode builds can be signed and sent to Apple for notarization if the necessary codesigning credentials are added as secrets to your repository. **You'll need a paid Apple Developer Account for this.** | ||
| To use code signing on GitHub Actions, the certificate and associated information need to be set up as _repository secrets_ in the GitHub repository's settings. | ||
|
|
||
| - On your Apple Developer dashboard, go to "Certificates, IDs & Profiles" and create two signing certificates: | ||
| - One of the "Developer ID Application" type. It will be used to sign the plugin's binaries | ||
| - One of the "Developer ID Installer" type. It will be used to sign the plugin's installer | ||
| - Using the Keychain app on macOS, export these two certificates and keys into a .p12 file **protected with a strong password** | ||
| - Encode the .p12 file into its base64 representation by running `base64 YOUR_P12_FILE` | ||
| - Add the following secrets in your Github repository settings: | ||
| - `MACOS_SIGNING_APPLICATION_IDENTITY`: Name of the "Developer ID Application" signing certificate generated earlier | ||
| - `MACOS_SIGNING_INSTALLER_IDENTITY`: Name of "Developer ID Installer" signing certificate generated earlier | ||
| - `MACOS_SIGNING_CERT`: Base64-encoded string generated above | ||
| - `MACOS_SIGNING_CERT_PASSWORD`: Password used to generate the .p12 certificate | ||
| - `MACOS_NOTARIZATION_USERNAME`: Your Apple Developer account's username | ||
| - `MACOS_NOTARIZATION_PASSWORD`: Your Apple Developer account's password (use a generated "app password" for this) | ||
| * First, the locally stored developer certificate needs to be exported from the macOS keychain: | ||
| * Using the Keychain app on macOS, export these your certificates (Application and Installer) public _and_ private keys into a single .p12 file **protected with a strong password** | ||
| * Encode the .p12 file into its base64 representation by running `base64 <NAME_OF_YOUR_P12_FILE>` | ||
| * Next, the certificate data and the password used to export it need to be set up as repository secrets: | ||
| * `MACOS_SIGNING_APPLICATION_IDENTITY`: Name of the "Developer ID Application" signing certificate | ||
| * `MACOS_SIGNING_INSTALLER_IDENTITY`: Name of "Developer ID Installer" signing certificate | ||
| * `MACOS_SIGNING_CERT`: The base64 encoded `.p12` file | ||
| * `MACOS_SIGNING_CERT_PASSWORD`: Password used to generate the .p12 certificate | ||
| * To also enable notarization on GitHub Action runners, the following repository secrets are required: | ||
| * `MACOS_NOTARIZATION_USERNAME`: Your Apple Developer account's _Apple ID_ | ||
| * `MACOS_NOTARIZATION_PASSWORD`: Your Apple Developer account's _generated app password_ | ||