[libmysofa] Adding port

[Honeybunch]

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

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

[WangWeiLin-MV]

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

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

[WangWeiLin-MV]

The port usage tests pass with the following triplets:

• x64-windows

[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]

Friendly bump 😸 Any other feedback?

[WangWeiLin-MV]

The port usage tests pass with the following triplets:

• x64-linux
• x64-windows
• x64-windows-static
• x86-windows

[dg0yt]

The port usage tests pass with the following triplets:

• x64-windows

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

Also not satisfied with #38368 (comment)

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

[JavierMatosD]

Everything except the skip-install-sample.patch looks good to me.

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.

It looks like its failing in downstream projects because the generate cmake targets file is injecting something like:

foreach(_cmake_target IN LISTS _cmake_import_check_targets)
  foreach(_cmake_file IN LISTS "_cmake_import_check_files_for_${_cmake_target}")
    if(NOT EXISTS "${_cmake_file}")
      message(FATAL_ERROR "The imported target \"${_cmake_target}\" references the file
   \"${_cmake_file}\"
but this file does not exist.  Possible reasons include:
* The file was deleted, renamed, or moved to another location.
* An install or uninstall procedure did not complete successfully.
* The installation package was faulty and contained
   \"${CMAKE_CURRENT_LIST_FILE}\"
but not all the files it references.")
    endif()
  endforeach()
endforeach()

I believe this happens as a consequence of install(EXPORT...)

[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 😩