[Spout2] New Port

[reitowo]

Fixes #30117

• Changes comply with the maintainer guide
• The name of the port matches an existing name for this component on https://repology.org/ if possible, and/or is strongly associated with that component on search engines.
• Optional dependencies are resolved in exactly one way. For example, if the component is built with CMake, all find_package calls are REQUIRED, are satisfied by vcpkg.json's declared dependencies, or disabled with CMAKE_DISABLE_FIND_PACKAGE_Xxx
• The versioning scheme in vcpkg.json matches what upstream says.
• The license declaration in vcpkg.json matches what upstream says.
• The installed as the "copyright" file matches what upstream says.
• The source code of the component installed comes from an authoritative source.
• The generated "usage text" is accurate. See adding-usage for context.
• The version database is fixed by rerunning ./vcpkg x-add-version --all and committing the result.
• Only one version is in the new port's versions file.
• Only one version is added to each modified port's versions file.

[jimwang118]

All feature passed with following triplets:

x64-windows
x64-windows-static

[dg0yt]

This comment was marked as resolved, but isn't IMO:

Vcpkg doesn't want to build both Spout2::Spout and Spout2::Spout_static in the same triplet. Only one will match the triplet's VCPKG_LIBRARY_LINKAGE.

[reitowo]

Only one will match the triplet's VCPKG_LIBRARY_LINKAGE.

Sure, but SpoutDX and SpoutLibrary use Spout_static as link dependency, so this target is got to be built. What can I do is prevent Spout_static being installed to vcpkg buildtree.

But after all, user still needs to import cmake target manually. I think it is ok for user to use Spout / Spout_static occasionally if they want static linkage according to the usage file says. In this situation, I think it makes no difference to prevent installing libs. What's more, it can keep upstream files untouched (which I remember is an preference of vcpkg).

[reitowo]

Why this still not merged?👀

[dg0yt]

Does this port need OpenGL-related dependencies?
It has

#include <gl/gl.h> // For OpenGL definitions

[dg0yt]

TBH I wonder if this makes sense to be a separate feature.

[reitowo]

This C-compatible library can also be switched on/off by SPOUT_BUILD_LIBRARY. It really doesn't make any significant difference (to me) about whether separating this option as a feature or making it default on. So I'll just leave it there, I think making this an option is better than making this default on anyway.

[dg0yt]

We can add features at any time, but it is disruptive to remove them.

AFAICS this library has C++ API, so c is a disnomer.
https://github.com/leadedge/Spout2/blob/master/SPOUTSDK/SpoutLibrary/SpoutLibrary.h

AFAIU it is just a tiny alternative DLL surface on top of Spout_static.
https://github.com/leadedge/Spout2/blob/master/SPOUTSDK/SpoutLibrary/CMakeLists.txt

That's why I'm reluctant to accept a feature c here.

[reitowo]

Sound reasonable, I'll remove that.

[reitowo]

Does this port need OpenGL-related dependencies?

Yes, but it seems included in Windows SDK and doesn't makes a dependency error on both my computer and CI.

[dg0yt]

Does this port need OpenGL-related dependencies?

Yes, but it seems included in Windows SDK and doesn't makes a dependency error on both my computer and CI.

It doesn't make errors, but vcpgk owners want port opengl to be used to make the dependency explicit.
(This has been discussed elsewhere. I just tell you. My POV: "I fail to see a robust benefit from the copying of SDK headers.")

[reitowo]

Thank for telling that, I'll add it.