While the system helped users get started quickly, it also presented a unique problem by itself. As CMake grew, the code that supported this system became more and more fragile to the point of failing at random, with no indication of why it would fail. Additionally as OBS Studio 28.0 adopted a much nicer system, it is no longer necessary to have this system at all.
As an addition to this change, all systems that could rely on FindModules now do so. This drastically reduces the complexity of the CMake system, while allowing significantly more flexibility with what binaries are really being used. In the best case this should allow a prepared user to build StreamFX by itself within seconds.
The runners "windows-2022" and "windows-2019" both come with almost identical software, and we can still target Windows 10 21H2. The same goes for "macos-12", "macos-11" and "macos-10.15", where we can simply target 10.15 and get the same result. Only Ubuntu does not make it easy, as it doesn't easily allow targeting a certain OS version.
There is no point in completely separating these, as CMake can build out-of-tree just fine. Thus we can reduce the overall complexity significantly, and also detect far more problems ahead of time. As a side bonus, we get both debug and release packages in one go.
* New translations en-US.ini (French)
* New translations en-US.ini (Sinhala)
* New translations en-US.ini (Arabic)
* New translations en-US.ini (Turkish)
* New translations en-US.ini (Romanian)
* New translations en-US.ini (Thai)
* New translations en-US.ini (Thai)
* New translations en-US.ini (Arabic)
* New translations en-US.ini (Arabic)
* New translations en-US.ini (Romanian)
This allows developers to pick their flavor of Qt, potentially enabling more advanced integrations with Qt in the future. Eventually Qt5 support may be dropped in favor of Qt6.
Fixes#811
* New translations en-US.ini (Arabic)
* New translations en-US.ini (Norwegian)
* New translations en-US.ini (Norwegian)
* New translations en-US.ini (Arabic)
* New translations en-US.ini (Thai)
* New translations en-US.ini (Ukrainian)
* New translations en-US.ini (Chinese Simplified)
* New translations en-US.ini (Chinese Traditional)
* New translations en-US.ini (Portuguese, Brazilian)
* New translations en-US.ini (English, United Kingdom)
* New translations en-US.ini (Sinhala)
* New translations en-US.ini (Turkish)
* New translations en-US.ini (Russian)
* New translations en-US.ini (Norwegian)
* New translations en-US.ini (Finnish)
* New translations en-US.ini (Romanian)
* New translations en-US.ini (French)
* New translations en-US.ini (Spanish)
* New translations en-US.ini (Czech)
* New translations en-US.ini (German)
* New translations en-US.ini (Portuguese)
* New translations en-US.ini (Hungarian)
* New translations en-US.ini (Italian)
* New translations en-US.ini (Japanese)
* New translations en-US.ini (Korean)
* New translations en-US.ini (Dutch)
* New translations en-US.ini (Polish)
* New translations en-US.ini (Norwegian)
* New translations en-US.ini (Hungarian)
* New translations en-US.ini (Romanian)
* New translations en-US.ini (Italian)
* New translations en-US.ini (Swedish)
* New translations en-US.ini (Polish)
* New translations en-US.ini (Polish)
* New translations en-US.ini (Russian)
* New translations en-US.ini (Korean)
* New translations en-US.ini (Thai)
To ensure better stability of future releases, we need to adopt multiple stages in the release cycle. As we already label Alpha, Beta, Candidate and Stable differently, simply adopting this classification system already does everything for us. This also allows us to maintain compatibility with the existing system, while offering something new entirely.
- Updates all workflow actions to the latest major version where possible.
- Updated GCC to version 10 on Ubuntu.
- Update Clang to version 14 on Ubuntu.
- Removed CodeQL as it turned out to be completely useless.
- Updated validation script.
- Updated build script
