The compiler will choose the optimal way automatically, and forcing std::move here actually results in two objects existing side by side, before being "moved" into one.
These warnings are mostly hints or complete nonsense based on broken parsing. It is easier to disable them than to find a common solution that works on all compilers.
* New translations en-US.ini (Russian)
* New translations en-US.ini (Czech)
* New translations en-US.ini (Italian)
* New translations en-US.ini (Spanish)
* New translations en-US.ini (Polish)
* New translations en-US.ini (Danish)
* New translations en-US.ini (Danish)
* New translations en-US.ini (Danish)
* New translations en-US.ini (Danish)
* New translations en-US.ini (Danish)
* New translations en-US.ini (French)
This work-around adds the necessary include directories, as the 'libobs' target does not export any include directories visible without BUILD_INTERFACE evaluating to TRUE. Hopefully the true cause for this problem can be identified and fixed later.
- Use auto in places where code clarity is improved or identical.
- Replace trivial constructors and destructors with default.
- Use true random for random generation.
- Use std::string_view where it is valid to do so.
- Apply const where it is valid to do so.
- Use references where it is valid to do so.
- Manually optimize memory usage with std::move and std::copy.
- Opt for memory efficient containers where the size is known ahead of time.
Signed-off-by: lainon <GermanAizek@yandex.ru>
For unknown reasons this results in an error only when the project is built within git-bash and with cmake. It does not occur with cmake-gui or VS itself.
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.
