frontend: Fix updates failing when configured without What's New

[RytoEX]

Description

The updates config folder is used to download files tied to update branch selection and application updates. If this folder does not exist, the downloads fail. Tying this folder creation to What's New, which also uses this folder, seems incorrect, since it is also uses for application updates. Remove the ifdef guard for folder creation.

Motivation and Context

Noticed while doing local testing for something else that the updater was failing to download update files. Realized my local build had WHATSNEW disabled because I had built without the browser. This probably shouldn't prevent the creation of the updates directory.

I know this folder is used on Windows and macOS. I cannot remember if it's used on Linux for anything.

How Has This Been Tested?

Tested builds locally with the browser disabled. The updater will now successfully download files and pop the OBSUpdate dialog window since it is not browser-based (unlike the What's New dialog).

Types of changes

• Bug fix (non-breaking change which fixes an issue)

Checklist:

• My code has been run through clang-format.
• I have read the contributing document.
• My code is not on the master branch.
• The code has been tested.
• All commit messages are properly formatted and commits squashed where appropriate.
• I have included updates to all appropriate documentation.

[Warchamp7]

Deferring to Pat on this for CMake stuff.

[PatTheMav]

The directory is tied to up to an overlapping set of features depending on platform:

• On Windows it seems required for updates themselves, "What's New" and branch selection.
• On macOS it's only required for "What's New" and branch selection.
• On Linux it's only required for "What's New".

On Linux and macOS it's closely tied to the presence of browser panels - while they are enabled by default in official macOS release builds, the architecture is built around them being optional.

I'm trying to think whether it's more beneficial to create this directory unconditionally (as the PR does) or whether to run even more possible permutations of build flags to decide this.

---

Annoyingly the branches file only seems to contain "any branches but the default branch" which is also a smell, but out of scope for this fix.

[RytoEX]

The directory is tied to up to an overlapping set of features depending on platform:

* On Windows it seems required for updates themselves, "What's New" and branch selection.

* On macOS it's only required for "What's New" and branch selection.

* On Linux it's only required for "What's New".

On Linux and macOS it's closely tied to the presence of browser panels - while they are enabled by default in official macOS release builds, the architecture is built around them being optional.

I'm trying to think whether it's more beneficial to create this directory unconditionally (as the PR does) or whether to run even more possible permutations of build flags to decide this.

We once had a CMake flag to disable updates and we intentionally removed that flag because it was too easy to accidentally ship a release build with it set which would break updates for that release. Given that case, our stance would seem to be "do not let OBS Studio builds be configured in a way that breaks updates".

I agree that the directory being used for multiple things is not ideal. I'm not sure if that is because of the shared code paths dictating the destination path for downloading the JSON files.

The "easiest" solution here besides this PR may be to add an UPDATE_BRANCHES_ENABLED feature flag that is controlled by a new frontend/cmake/feature-update-branches.cmake that sets the flag accordingly based on OS/platform (see your list above), and then gate directory creation on #if defined(WHATSNEW_ENABLED) || defined(UPDATE_BRANCHES_ENABLED) or something. I'm just not sure it's worth the extra code.

The more complex solution may be to untangle updates from "What's New", though one may argue that "What's New" does convey information about updates, so I'm not sure if that's correct either.

[PatTheMav]

We once had a CMake flag to disable updates and we intentionally removed that flag because it was too easy to accidentally ship a release build with it set which would break updates for that release. Given that case, our stance would seem to be "do not let OBS Studio builds be configured in a way that breaks updates".

I agree that the directory being used for multiple things is not ideal. I'm not sure if that is because of the shared code paths dictating the destination path for downloading the JSON files.

The "easiest" solution here besides this PR may be to add an UPDATE_BRANCHES_ENABLED feature flag that is controlled by a new frontend/cmake/feature-update-branches.cmake that sets the flag accordingly based on OS/platform (see your list above), and then gate directory creation on #if defined(WHATSNEW_ENABLED) || defined(UPDATE_BRANCHES_ENABLED) or something. I'm just not sure it's worth the extra code.

Yeah my feelings exactly. I don't think that having that directory around by default is a problem and not having to introduce additional build system flags (and compiler definitions) also seems preferable to me.