Add in-tree build support

[tytan652]

Description

Resolve #10

• The plugin template can be built outside or inside OBS Studio Build tree.
• Linkage to the frontend API and Qt are "disabled" since they are not used by the example.
• I tried to keep the template simple

Note: The Windows only RC file was not added, I just don't know if it's needed for testing and debugging.

Motivation and Context

I just wanted to do it.

How Has This Been Tested?

• Build the plugin out of tree, and test the plugin with OBS Studio
• Build the plugin in OBS Studio build tree, and run the built OBS Studio and check if the plugin is built and loaded.

Types of changes

• New feature (non-breaking change which adds functionality)

• Documentation (a change to documentation pages)

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.

[PatTheMav]

The whole idea of the plugintemplate is to move people away from in-tree builds, but instead manage plugins as their own independent projects with libobs (and if necessary obs-frontend-api) as external library dependencies.

This also gently forces developers to write their plugins in a more standalone fashion which helps us down the line with API changes, plugin sandboxing, or other security-related functionality we might envision.

There is a CMake option to have the resulting artifact be copied into an OBS build's rundir automatically for testing, but development wise in-tree development is discouraged.

[RytoEX]

I agree with @PatTheMav . We should not be encouraging in-tree building for plugins that are not the core plugins already in the obs-studio repo.

[tytan652]

Ok, so I close the PR.

[PatTheMav]

@tytan652 If you got any feedback about any issues arising from this change (i.e. pain points, missing explanation, unclearities), please let us know.

I guess the discussions forum on the obs-studio project would be a good place to let us know.

[tytan652]

Like #10 explains it, I just though that enabling in-tree build for easier testing and debugging purpose would be a good idea. This feature is not meant for releasing plugins.

• I wanted to avoid the whole copy paste at each plugins build, and just put the project in the plugins folder and add a cmake add_subdirectory.
• Many plugins have already this behavior in their CMake.

[PatTheMav]

Well the easiest way to achieve that is to tell CMake to install the plugin into the plugins path of the OBS instance you test with.

That will ensure the plugin ends up automatically where it should be and you don't have to re-build OBS every time you changed something about the plugin and just restart your OBS instance.

[cpyarger]

To be fair, you don't end up rebuilding obs each time you make a plugin change, as cmake handles only rebuilding things that have changed.

The biggest issues I have had previously with building out of tree is based around debugging and occasionally function autocompletion for obs api functions. I have never been able to figure out how to get Visual Studio to properly resolve all of the debugging symbols.