[libmysofa] Adding port

[Honeybunch]

• [X] Changes comply with the maintainer guide.
• [X] 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.
• [X] 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.
• [X] The versioning scheme in vcpkg.json matches what upstream says.
• [X] The license declaration in vcpkg.json matches what upstream says.
• [X] The installed as the "copyright" file matches what upstream says.
• [X] The source code of the component installed comes from an authoritative source.
• [X] The generated "usage text" is accurate. See adding-usage for context.
• [X] The version database is fixed by rerunning ./vcpkg x-add-version --all and committing the result.
• [X] Only one version is in the new port's versions file.
• [X] Only one version is added to each modified port's versions file.

This is a dependency that steam-audio needs and I'm trying to get steam-audio ported here too 😄

[dg0yt]

IMO the CMake changes are to invasive. Output names and exported target names can be adjusted with properties. CMake config can be moved by vcpkg_cmake_config_fixup(... CONFIG_PATH ...).

[Honeybunch]

Yeah I can do that. I always forget about the arguments to config_fixup

[Honeybunch]

Looks like the CI here failed connecting to an agent

[dg0yt]

Could you please help sync the CMake config and __declspec(dllexport) patch to upstream?

Unless the __declspec(dllexport) patch is accepted upstream, a separate .def file would be much less invasive and more maintainable as part of the port.

[data-queue]

This PR fetches from a separate fork, and since it introduces a significant change, I think we need to wait for upstream to accept it.

[Honeybunch]

Yeah I'm doing my best to get this upstreamed. I think I have a change that meets their feedback that will work but it hasn't gotten any movement yet 😞

[Honeybunch]

I finally got my change in for upstream. Updating the port now :)

[Honeybunch]

Friendly bump 😸 Any other feedback?

[dg0yt]

The port usage tests pass with the following triplets:

• x64-windows

You must test with a static triplet, due to https://github.com/microsoft/vcpkg/pull/38368#discussion_r1758183614

Also not satisfied with https://github.com/microsoft/vcpkg/pull/38368#discussion_r1753106083

[WangWeiLin-MV]

You must test with a static triplet, due to #38368 (comment)

Thanks for the reminder, I tested the triplets.

And the find_dependency(ZLIB) exist in upstream. https://github.com/hoene/libmysofa/blob/v1.3.2/mysofaConfig.cmake.in#L6

Also not satisfied with #38368 (comment)

I re-opened the thread.

[Honeybunch]

I could use some clarification on how these sofa files are used. For example, is it expected that they will be present in both debug and release builds or only for release.

They are data files that represent head relative transfer functions. There is no difference between debug and release. Libmysofa is for parsing these files so you could think of the sofa files here as samples/test data. A library user would most likely want to read their own sofa files which is why I opted to simply skip installing them. Would a better solution be a patch that just skips exporting but still installs the default sofa files?

[JavierMatosD]

I could use some clarification on how these sofa files are used. For example, is it expected that they will be present in both debug and release builds or only for release.

They are data files that represent head relative transfer functions. There is no difference between debug and release. Libmysofa is for parsing these files so you could think of the sofa files here as samples/test data. A library user would most likely want to read their own sofa files which is why I opted to simply skip installing them. Would a better solution be a patch that just skips exporting but still installs the default sofa files?

If the files don't need to be exported then I think skipping the export would solve the issue for downstream projects along with deleting the sofa files so that vcpkg doesn't complain about files living in debug/share.

Don't forget to mark this PR "Ready for Review" when you are ready so I know to check back in.

[dg0yt]

The actual problem with default.sofa is the fact that it is a symlink in git and doesn't exist when unpacked on Windows. libmysofa fails to build from source when it tries to install the non-existing file.

[Honeybunch]

The actual problem with default.sofa is the fact that it is a symlink in git and doesn't exist when unpacked on Windows. libmysofa fails to build from source when it tries to install the non-existing file.

Oh shoot I didn't notice that. That makes a lot more sense. Thanks

[Honeybunch]

If the files don't need to be exported then I think skipping the export would solve the issue for downstream projects along with deleting the sofa files so that vcpkg doesn't complain about files living in debug/share.

Coming back to this I'm a bit confused. We do still want to export the libmysofa library target and the .sofa files are just installed with install(FILE ... DESTINATION ...) so I don't understand why we would want to skip export. I must be misunderstanding something :)

[Honeybunch]

Yeah if I just delete the file my downstream project complains when it tries to install the libmysofa package just as @dg0yt described. Only happens on Windows 🤔

CMake Error at cmake_install.cmake:36 (file):
  file INSTALL cannot find
  "C:/Users/<user>/scoop/apps/vcpkg/current/buildtrees/libmysofa/src/15e1ab997b-72a28a9863.clean/share/default.sofa":
  File exists.

Sorry, I clearly made some bad assumptions about what exactly was going on here

[JavierMatosD]

Thank you @Honeybunch for the contribution and thank you @dg0yt for all the assistance!

[Honeybunch]

Thanks everyone. Sorry it took so long to get this one ironed out 😩