|
1 | 1 | # OBS Plugin Template |
2 | 2 |
|
3 | | -## Introduction |
| 3 | +## RICHARD- HEADER STUFF HERE |
4 | 4 |
|
5 | | -The plugin template is meant to be used as a starting point for OBS Studio plugin development. It includes: |
| 5 | +## Build Instructions |
| 6 | +Currently the Elgato Marketplace Connect plugin can only be built on Windows. The plugin uses the OBS plugin template build system, and more detailed build instructions can be found on the [template project's wiki](https://github.com/obsproject/obs-plugintemplate/wiki). |
6 | 7 |
|
7 | | -* Boilerplate plugin source code |
8 | | -* A CMake project file |
9 | | -* GitHub Actions workflows and repository actions |
| 8 | +### Build system requirements |
| 9 | +Two sets of development tools are required. Ensure both are installed prior to configuring and building the plugin: |
10 | 10 |
|
11 | | -## Set Up |
| 11 | +* Visual Studio 17 2022 |
| 12 | +* CMake 3.30.5 |
12 | 13 |
|
13 | | -The plugin project is set up using the included `buildspec.json` file. The following fields should be customized for an actual plugin: |
| 14 | +### Building the project |
| 15 | +After making sure the required development tools are installed, building the plugin should be a straightforawrd process. |
14 | 16 |
|
15 | | -* `name`: The plugin name |
16 | | -* `version`: The plugin version |
17 | | -* `author`: Actual name or nickname of the plugin's author |
18 | | -* `website`: URL of a website associated with the plugin |
19 | | -* `email`: Contact email address associated with the plugin |
20 | | -* `uuids` |
21 | | - * `macosPackage`: Unique (**!**) identifier for the macOS plugin package |
22 | | - * `macosInstaller`: Unique (**!**) identifier for the macOS plugin installer |
23 | | - * `windowsApp`: Unique (**!**) identifier for the Windows plugin installer |
| 17 | +1. Configuration: in a terminal window, navigate to the root plugin folder, and configure the project files with: `cmake --preset windows-x64`. This will download any build dependencies and set up a Visual Studio project file in a new project directory called `build_x64`. |
| 18 | +2. Inside the new `build_x64` directory added to the projects root, you will find a `elgato-marketplace-connect.sln` file. Open this file in Visual Studio to edit and build the project. |
| 19 | +3. Alternatively, cmake can build the project directly with the command: `cmake --build --preset windows-x64`. |
24 | 20 |
|
25 | | -These values are read and processed automatically by the CMake build scripts, so no further adjustments in other files are needed. |
26 | | - |
27 | | -### Platform Configuration |
28 | | - |
29 | | -Platform-specific settings are set up in the `platformConfig` section of the buildspec file: |
30 | | - |
31 | | -* `bundleId`: macOS bundle identifier for the plugin. Should be unique and follow reverse domain name notation. |
32 | | - |
33 | | -### Set Up Build Dependencies |
34 | | - |
35 | | -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). |
36 | | - |
37 | | -#### Choose An OBS Studio Version |
38 | | - |
39 | | -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: |
40 | | - |
41 | | -* 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 |
42 | | -* 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 |
43 | | -* 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) |
44 | | - |
45 | | -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. |
46 | | - |
47 | | -#### Windows and macOS |
48 | | - |
49 | | -Windows and macOS dependency downloads are configured in the `buildspec.json` file: |
50 | | - |
51 | | -* `dependencies`: |
52 | | - * `obs-studio`: Version of OBS Studio to build plugin with (needed for `libobs` and `obs-frontend-api`) |
53 | | - * `prebuilt`: Prebuilt OBS Studio dependencies |
54 | | - * `qt6`: Prebuilt version of Qt6 as used by OBS Studio |
55 | | -* `tools`: Contains additional build tools used by CI |
56 | | - |
57 | | -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. |
58 | | - |
59 | | -To update a dependency, change the `version` and associated `hashes` entries to match the new version. The used hash algorithm is `sha256`. |
60 | | - |
61 | | -#### Linux |
62 | | - |
63 | | -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: |
64 | | - |
65 | | -* Build System Dependencies: |
66 | | - * `cmake` |
67 | | - * `ninja-build` |
68 | | - * `pkg-config` |
69 | | -* Build Dependencies: |
70 | | - * `build-essential` |
71 | | - * `libobs-dev` |
72 | | -* Qt6 Dependencies: |
73 | | - * `qt6-base-dev` |
74 | | - * `libqt6svg6-dev` |
75 | | - * `qt6-base-private-dev` |
76 | | - |
77 | | -## Build System Configuration |
78 | | - |
79 | | -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: |
80 | | - |
81 | | -* `macos` |
82 | | - * Universal architecture (supports Intel-based CPUs as Apple Silicon) |
83 | | - * Defaults to Qt version `6` |
84 | | - * Defaults to macOS deployment target `11.0` |
85 | | -* `macos-ci` |
86 | | - * Inherits from `macos` |
87 | | - * Enables compile warnings as error |
88 | | -* `windows-x64` |
89 | | - * Windows 64-bit architecture |
90 | | - * Defaults to Qt version `6` |
91 | | - * Defaults to Visual Studio 17 2022 |
92 | | - * Defaults to Windows SDK version `10.0.18363.657` |
93 | | -* `windows-ci-x64` |
94 | | - * Inherits from `windows-x64` |
95 | | - * Enables compile warnings as error |
96 | | -* `linux-x86_64` |
97 | | - * Linux x86_64 architecture |
98 | | - * Defaults to Qt version `6` |
99 | | - * Defaults to Ninja as build tool |
100 | | - * Defaults to `RelWithDebInfo` build configuration |
101 | | -* `linux-ci-x86_64` |
102 | | - * Inherits from `linux-x86_64` |
103 | | - * Enables compile warnings as error |
104 | | -* `linux-aarch64` |
105 | | - * Provided as an experimental preview feature |
106 | | - * Linux aarch64 (ARM64) architecture |
107 | | - * Defaults to Qt version `6` |
108 | | - * Defaults to Ninja as build tool |
109 | | - * Defaults to `RelWithDebInfo` build configuration |
110 | | -* `linux-ci-aarch64` |
111 | | - * Inherits from `linux-aarch64` |
112 | | - * Enables compile warnings as error |
113 | | - |
114 | | -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. |
115 | | - |
116 | | -Additional build system options are available to developers: |
117 | | - |
118 | | -* `ENABLE_CCACHE`: Enables support for compilation speed-ups via ccache (enabled by default on macOS and Linux) |
119 | | -* `ENABLE_FRONTEND_API`: Adds OBS Frontend API support for interactions with OBS Studio frontend functionality (disabled by default) |
120 | | -* `ENABLE_QT`: Adds Qt6 support for custom user interface elements (disabled by default) |
121 | | -* `CODESIGN_IDENTITY`: Name of the Apple Developer certificate that should be used for code signing |
122 | | -* `CODESIGN_TEAM`: Apple Developer team ID that should be used for code signing |
123 | | - |
124 | | -## GitHub Actions & CI |
125 | | - |
126 | | -Default GitHub Actions workflows are available for the following repository actions: |
127 | | - |
128 | | -* `push`: Run for commits or tags pushed to `master` or `main` branches. |
129 | | -* `pr-pull`: Run when a Pull Request has been pushed or synchronized. |
130 | | -* `dispatch`: Run when triggered by the workflow dispatch in GitHub's user interface. |
131 | | -* `build-project`: Builds the actual project and is triggered by other workflows. |
132 | | -* `check-format`: Checks CMake and plugin source code formatting and is triggered by other workflows. |
133 | | - |
134 | | -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. |
135 | | - |
136 | | -### Retrieving build artifacts |
137 | | - |
138 | | -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. |
139 | | - |
140 | | -### Building a Release |
141 | | - |
142 | | -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. |
143 | | - |
144 | | -## Signing and Notarizing on macOS |
145 | | - |
146 | | -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: |
147 | | - |
148 | | -* On your Apple Developer dashboard, go to "Certificates, IDs & Profiles" and create two signing certificates: |
149 | | - * One of the "Developer ID Application" type. It will be used to sign the plugin's binaries |
150 | | - * One of the "Developer ID Installer" type. It will be used to sign the plugin's installer |
151 | | - |
152 | | -The developer certificate will usually carry a name similar in form to |
153 | | - |
154 | | -`Developer ID Application: <FIRSTNAME> <LASTNAME> (<LETTERS_AND_NUMBERS>)` |
155 | | - |
156 | | -This entire string should be specified as `CODESIGN_IDENTITY`, the `LETTERS_AND_NUMBERS` part as `CODESIGN_TEAM` to CMake to set up codesigning properly. |
157 | | - |
158 | | -### GitHub Actions Set Up |
159 | | - |
160 | | -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. |
161 | | - |
162 | | -* First, the locally stored developer certificate needs to be exported from the macOS keychain: |
163 | | - * 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** |
164 | | - * Encode the .p12 file into its base64 representation by running `base64 <NAME_OF_YOUR_P12_FILE>` |
165 | | -* Next, the certificate data and the password used to export it need to be set up as repository secrets: |
166 | | - * `MACOS_SIGNING_APPLICATION_IDENTITY`: Name of the "Developer ID Application" signing certificate |
167 | | - * `MACOS_SIGNING_INSTALLER_IDENTITY`: Name of "Developer ID Installer" signing certificate |
168 | | - * `MACOS_SIGNING_CERT`: The base64 encoded `.p12` file |
169 | | - * `MACOS_SIGNING_CERT_PASSWORD`: Password used to generate the .p12 certificate |
170 | | -* To also enable notarization on GitHub Action runners, the following repository secrets are required: |
171 | | - * `MACOS_NOTARIZATION_USERNAME`: Your Apple Developer account's _Apple ID_ |
172 | | - * `MACOS_NOTARIZATION_PASSWORD`: Your Apple Developer account's _generated app password_ |
| 21 | +If you wish to debug the plugin within a running OBS, the (Project Wiki)[https://github.com/obsproject/obs-plugintemplate/wiki/How-To-Debug-Your-Plugin#debugging-plugins-with-visual-studio] has some great instructions. We recommend using the second variant (Adding the plugin to an OBS Studio Project), and when doing so, you will need to add the plugin project, plugin-support project, and the elgato-marketplace-connect-loader project to the solution explorer (step 2 in the instructions there). |
0 commit comments