[vcpkg-ci-msh3] New test port

[dg0yt]

No description provided.

[dg0yt]

@nibanks This is the sad state of port msh3's exported config in vcpkg.

(I can push fixes and updates once CI completes. This is my only source of MSVC logs.)

[nibanks]

@nibanks This is the sad state of port msh3's exported config in vcpkg.

(I can push fixes and updates once CI completes. This is my only source of MSVC logs.)

What is needed from msh3 to make this better?

[dg0yt]

What is needed from msh3 to make this better?

The only immediate suggestuion is to have a similar test upstream: Add a CI step which configures and builds (and maybe runs) an independent CMake test project based on the canonical CMake usage pattern. This catches missing properites and transitive usage requirements. (If transitive linking requirements are the blocker for offering a static lib, this would be a building block to improve the situation.) Similar for pkg-config.

This test port passes now, and I can update msh3 here on that base. Let's see what is still needed then. Of course it would be nice to not need patching in order to de-vendor msquic and ls-qpack, and to simply follow explicit toolchain choices.

[dg0yt]

Oh, great. Upgrade msh3 needs upgrading msquic. And we get a wonderful clash of the non-namespaced CMake targets (e.g. inc). Needs more work.

[dg0yt]

After updating msquic (WIP):

msquic provides CMake targets:

  # this is heuristically generated, and may not be correct
  find_package(msquic CONFIG REQUIRED)
  # note: 4 additional targets are not displayed.
  target_link_libraries(main PRIVATE inc msquic OpenSSL warnings)

The additional targets are msquic_platform, logging_inc, main_binary_link_args, OpenSSLQuic.
logging_inc, main_binary_link_args do not carry any properties.

I would assume that msquic should be the public CMake interface, pulling in everything which is needed to use msquic.

The port only support dynamic library linkage ATM. Upstream supports both, but doesn't prvovide exported config for the static lib. It is not create with add_library. In general, it would be desirable to have the same target name, with proper namespace, i.e. msquic::msquic.

[dg0yt]

#41219 disabled uwp for msquic due to (a variation of) this error:

OneCore.lib(KERNEL32.dll) : error LNK2005: VirtualAlloc already defined in msquic_platform.lib(datapath_winuser.c.obj)
   Creating library obj\Debug\msquic.lib and object obj\Debug\msquic.exp
bin\Debug\msquic.dll : fatal error LNK1169: one or more multiply defined symbols found

The error didn't really make sense to me wrt msquic_platform.lib(datapath_winuser.c.obj), and I started to look at other link libs appearing after msquic_platform.lib until (incl.) OneCore.lib. I also looked at GHA logs in the msquic repo. (But they don't use the ninja generator.)
I was now able to track this down to the use of "ONECORE" instead of "UWP" in openssl3.

@nibanks Maybe you can help answer questions also for msquic? I'm always a litte bit last in the past, present and future of Microsoft platforms.

• Choose schannel or openssl as default windows configuruation?
  Should the default installation of the msquic port on Windows use openssl3?
  AFAIU msquic default choice is schannel, but this choice doesn't offer the 0-RTT capability,
  https://github.com/microsoft/msquic/blob/main/docs/Platforms.md
  (vcpkg CI could still run with the capability enabled, via the test port requesting a new 0-rtt feature.)
• Link OneCore, OneCoreUap, or WindowsApp?
  AFAIU OneCore must not be chosen for UWP,
  https://learn.microsoft.com/en-us/windows/win32/apiindex/windows-umbrella-libraries
  The linker error shown above disappers when configuring openssl for UWP instead of ONECORE. (This is what the pristine openssl vcpkg port does.)
• Avoid winmm.lib?
  Support High Resolution Timer (WinUser) msquic#2300 added optional support for high resolution timers, with unconditional linking of winmm.lib.
  AFAIU timeGetDevCaps etc. are not available for UWP apps,
  https://learn.microsoft.com/en-us/windows/win32/api/timeapi/nf-timeapi-timegetdevcaps
  (The use of this particular function isn't even guarded by the CMake option.)