[projectm4] Add new port

[Blaquewithaq]

This is a new overlay-port to add the ProjectM library: https://github.com/projectM-visualizer/projectm

• 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.

[Blaquewithaq]

@microsoft-github-policy-service agree

[WangWeiLin-MV]

The port usage tests pass with the following triplets:

• x64-linux
• x64-windows

[dg0yt]

Nit-pick:

Suggested change

PACKAGE_NAME "projectm4"

The default name is the port name, so this line is redundant.
But I acknowledge that it helps to mark the difference from the second config.

[dg0yt]

Suggested change

	REF "f60cd86"
	REF f60cd86ab687e7b65e6e36a8f0a606dd1141ea23

It might be desirable to switch the regular version scheme in the future, which would allow to express git tags like v${VERSION}.

[WangWeiLin-MV]

Thanks @dg0yt .
@Blaquewithaq Could you help switch to the release version like https://github.com/projectM-visualizer/projectm/releases/tag/v4.1.1?

[kblaschke]

Could you help switch to the release version like https://github.com/projectM-visualizer/projectm/releases/tag/v4.1.1?

This was already discussed above, we had to make a small change in the build system in response to the above discussion, and this commit is not in the 4.1.1 release. So to resolve this, we have basically three options:

1. We can revert to the 4.1.1 version and have to use the submodule option for the projectm-eval dependency, which, as stated, was requested to be changed to an external dependency.
2. Use the commit hash as-is in the port, which, apart from some cosmetic and GitHub-related changes, is essentially the same as v4.1.1
3. Wait until the next projectM version is released which includes the projectm-eval dependency fix for vcpkg. In this case, we should close/draft this PR, as this might take a few months like Blaque said.

I'd personally be fine with keeping the commit hash, even if it's not perfect, and when we've released the next version (either 4.1.2 or 4.2.0), we'd update the port and go back to using the variable-based version tag instead.

[dg0yt]

I'd personally be fine with keeping the commit hash, even if it's not perfect, and when we've released the next version (either 4.1.2 or 4.2.0), we'd update the port and go back to using the variable-based version tag instead.

IMO that's fine for the first version of the new port.
And my suggested change is to use the full SHA1 now, not to switch versioning now.

[WangWeiLin-MV]

It looks like the common name of https://github.com/projectM-visualizer/projectm is projectM, could you help to confirm?

[kblaschke]

"projectM" is the overall project/library name, but since there's been a huge change beween v3 and v4 regarding the overall API, and v4 is relatively new and not yet adopted widely, it makes sense to put the major number into the port name, which is also reflected in the CMake package name find_package(projectM4) as well.

This is very similar to other libraries which exist in different versions, e.g. libSDL, which exists as ports sdl1, sdl2 and sdl3 for each respective major version.

We'd like to continue using the 4 suffix to disambiguate multiple major versions of projectM, especially as there are plans for an upcoming version 5 which will have different features and additional dependencies, e.g. the Vulkan SDK.

[dg0yt]

I noticed the inconsistencies, too, but I didn't want to open this discussion, assuming a deliberate choice.

It is normal for major versions to break things. And vcpkg probably will not allow to install different versions side-by-side unless headers and symbols have distinct filepaths/symbols. Adding version 5 may mean to remove version 4, at least from vcpkg CI. (Even openssl 1.1 wasn't accepted to stay when merging openssl 3.0.)

Repology.org indicates that other repositories keep the "projectm" name for version 4.

The long name matches the CMake package name, and and the package name is a ship which seems to have sailed with 4.0.1. However, cmake package name and port name do not need to match, and cmake config may implement a same-major-version matching policy for a given name, when the user supplies the desired version.

[WangWeiLin-MV]

"projectM" is the overall project/library name, but since there's been a huge change beween v3 and v4 regarding the overall API, and v4 is relatively new and not yet adopted widely, it makes sense to put the major number into the port name, which is also reflected in the CMake package name find_package(projectM4) as well.

About the API, as @dg0yt 's comment. And for the find_package, this find modules is not typically provided by the package itself

This is very similar to other libraries which exist in different versions, e.g. libSDL, which exists as ports sdl1, sdl2 and sdl3 for each respective major version.

Some packages exist more than one port was retained for backwards compatibility. And for projectM, according to the branch and release status, there's no old version released.

We'd like to continue using the 4 suffix to disambiguate multiple major versions of projectM, especially as there are plans for an upcoming version 5 which will have different features and additional dependencies, e.g. the Vulkan SDK.

Same as the first comment.

[kblaschke]

About the API, as @dg0yt 's comment. And for the find_package, this find modules is not typically provided by the package itself

Please note projectM uses Config packages now, not the old CMake Find modules. Config packages must be provided by the package, because they contain a lot of build-time information like versions, compiler flags used etc. which are specific to this package build. This is also stated in the linked documentation, reading "The config and version files are typically installed as part of the package".

This is especially true as projectM adds some important dependency flags into the configuration file, which downstream users need to properly link and run the library. Creating these files externally, or providing a generic Find module in the port will not work.

Some packages exist more than one port was retained for backwards compatibility. And for projectM, according to the branch and release status, there's no old version released.

We can of course remove the suffix from the port, and just go with projectm for now. But we'll have to add this suffix for the next major version to prevent losing this backwards compatibility. Then vcpkg will have one unsuffixed port projectm for 4.x releases, and one suffixed port projectm5 for 5.x releases. If that's the way it's handled in vcpkg, that's fine, but should be documented and clearly stated somewhere to avoid any lengthy discussion on this topic.

Besides that, here's the previous release: https://github.com/projectM-visualizer/projectm/releases/tag/v3.1.12
Due to the way the project was handled in the past in regards to versioning, there's no branch, just a tag. But it is there.

[Blaquewithaq]

4.1.1 does not have support for vcpkg. I had to add code to make it vcpkg compatible. I can switch it back to version when they release 4.1.2 but until then it has to remain as is to work.

[kblaschke]

To shorten this whole discussion and get the port merged in a good way - I'd like to ask @WangWeiLin-MV (or some other maintainer) what's actually left for us to change before the port is ready for merging? To summarize, I find these points which are the requested changes:

• Rename the port to projectm
• Add "name": "projectm" to vcpkg.json (which is a requirement for libraries)
• Use the long commit hash for checkout until the next version is released (we'll update the port ASAP after that happens to use the v${VERSION} syntax to choose a tag instead)
• Remove redundant PACKAGE_NAME "projectm4" line from portfile.cmake

Is this the actual list to tick off and get the review done?

Any other discussion points. e.g. regarding the handling of CMake Config package files, I can hardly understand why this would be an issue since all other ports using such files also install those from the actual package, and the ports don't provide find modules or any special treatment in the portfile.

I also don't get the comment About the API, as @dg0yt 's comment. above, as dg0yt didn't even say something about the API in his comments. Is there an issue with projectM's API which is relevant to this port (except the basic API stability considerations between major/minor version, which apply here)?

[WangWeiLin-MV]

@kblaschke and @Blaquewithaq

• A single vcpkg instance carries a single version for a particular dependency, unless the upstream explicitly releases multiple versions at the same time (i.e. treated as different packages) (Here is a discuss).
• Compatibility of upstream packages is determined by upstream. In particular, as a general convention, incompatible APIs are expected behavior of upgrading major version.
• For end users, vcpkg allows you to control the precise versions of each dependency in your project.

Therefore, only projectm should be provided, and also should not add version-marked port for new version.

[WangWeiLin-MV]

Note: I will be converting your PR to draft status. When you respond, please revert to "ready for review". That way, I can be aware that you've responded since you can't modify the tags.