docs: the Windows plugin dir is ProgramData, not the config dir
Build / macOS (macos-latest) (push) Successful in 36s
Build / Linux (ubuntu-24.04) (push) Successful in 55s
Build / macOS (macos-latest) (pull_request) Successful in 33s
Build / Linux (ubuntu-24.04) (pull_request) Successful in 1m9s
Build / Windows (windows-latest) (push) Successful in 10m51s
Build / Windows (windows-latest) (pull_request) Successful in 10m27s
Build / macOS (macos-latest) (push) Successful in 36s
Build / Linux (ubuntu-24.04) (push) Successful in 55s
Build / macOS (macos-latest) (pull_request) Successful in 33s
Build / Linux (ubuntu-24.04) (pull_request) Successful in 1m9s
Build / Windows (windows-latest) (push) Successful in 10m51s
Build / Windows (windows-latest) (pull_request) Successful in 10m27s
The packaging section claimed `<config>/obs-studio/plugins/<name>/bin/64bit` is "exactly the layout OBS searches on Linux and Windows". The layout is right; the base directory is not the same on both. obs-studio's `AddExtraModulePaths()` uses `GetAppConfigPath` on Linux/macOS but `GetProgramDataPath` (`CSIDL_COMMON_APPDATA`) on Windows, so Windows scans `C:\ProgramData\obs-studio\plugins\`, never `%APPDATA%\obs-studio\` (`CSIDL_APPDATA`) — which on Windows is where OBS keeps its config. This bit a director on 2026-09-09: a correctly-shaped install under `AppData\Roaming` produced an OBS log with zero mention of the module. Noted here because the failure is silent — OBS names any module it finds but cannot use, so an absence of any line means the file is not on a scanned path at all. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01AzGnvQ6wfD7bw7PZN35ft9
This commit is contained in:
@@ -161,10 +161,19 @@ build/package/licenses/...
|
|||||||
```
|
```
|
||||||
|
|
||||||
That is exactly the layout OBS searches on Linux and Windows —
|
That is exactly the layout OBS searches on Linux and Windows —
|
||||||
`<config>/obs-studio/plugins/<name>/bin/64bit` plus a sibling `data/`, per
|
`<base>/obs-studio/plugins/<name>/bin/64bit` plus a sibling `data/`, per
|
||||||
`AddExtraModulePaths()` in obs-studio's `UI/window-basic-main.cpp` — so
|
`AddExtraModulePaths()` in obs-studio (`UI/window-basic-main.cpp` in 30.x,
|
||||||
`build/package/` is a straight drop-in. The module resolves the LiveKit
|
`frontend/widgets/OBSBasic.cpp` in 32.x) — so `build/package/` is a straight
|
||||||
libraries from `$ORIGIN` (verified: `ldd` on the staged copy resolves both
|
drop-in. **`<base>` is NOT the same directory on every platform**, and getting
|
||||||
|
this wrong is silent: OBS logs nothing at all for a plugin it never finds.
|
||||||
|
Linux uses the user config dir (`GetAppConfigPath` → `~/.config`), but Windows
|
||||||
|
uses `GetProgramDataPath` (`CSIDL_COMMON_APPDATA`) — i.e.
|
||||||
|
`C:\ProgramData\obs-studio\plugins\`, **not** `%APPDATA%\obs-studio\`
|
||||||
|
(`CSIDL_APPDATA`), which on Windows holds OBS's config and is never scanned for
|
||||||
|
plugins. This bit a director on 2026-09-09: a correctly-shaped install under
|
||||||
|
`AppData\Roaming` produced a log with zero mention of the module.
|
||||||
|
|
||||||
|
The module resolves the LiveKit libraries from `$ORIGIN` (verified: `ldd` on the staged copy resolves both
|
||||||
to `bin/64bit/`), not from the build tree. macOS is not this shape; see the
|
to `bin/64bit/`), not from the build tree. macOS is not this shape; see the
|
||||||
macOS packaging gap under CI.
|
macOS packaging gap under CI.
|
||||||
|
|
||||||
|
|||||||
Reference in New Issue
Block a user