@jimwang118 & @BillyONeal this change is unnecessary, as QUIC_BUILD_TOOLS is disabled by default.

#39500 removes it

@jimwang118 & @BillyONeal this notion of tools as a feature should simply be removed. Tools are generally for internal use, and you're not setting the cmake flag to enable them (and shouldn't IMO) anyways.

The CMake flag was set when ms-quic[tools] by:

vcpkg_check_features(OUT_FEATURE_OPTIONS FEATURE_OPTIONS
    FEATURES
        tools QUIC_BUILD_TOOLS
)

#39500 removes the tools feature

@jimwang118 & @BillyONeal since you're overwriting v1.2.0, should this version stay here or be removed?

Old versions are never removed from the versions database. If someone has an override and explicitly asks for 1.2.0 this is how that gets found.

In this vcpkg_cmake_configure, Windows should default to schannel, but provide the option (a feature?) to override and set to openssl. Linux only supports openssl so it can stay as is.

It isn't clear how that can be a feature; it sounds like an alternative. See https://learn.microsoft.com/vcpkg/contributing/maintainer-guide#do-not-use-features-to-implement-alternatives . In particular, it is not possible for a consumer to require that a feature is off. It may be that overlays are required to express this difference; that's a common limitation for multiple TLS backends available like this.

Upstream documents that there are pretty substantial limitations (only working on very recent Windows, missing features) in https://github.com/microsoft/msquic/blob/main/docs/Platforms.md#windows to using the schannel backend.

I would welcome an upstream maintainer doing this surgery and explaining why the openssl backend is bad but I don't myself have a good enough understanding of the situation to do it myself.

I still don't quite understand the rest of these changes, and it'd be great to get them pushed upstream if really necessary. I (as the owner of msquic) would be happy to take them and cherry-pick them into the release branch to help here.

These changes are fixing up the upstream build system to create CMake targets consistent with vcpkg's installation layout. Since that's fairly vcpkg specific we wouldn't always upstream something like that.

We work out of the box with the most common CMake conventions. If upstream wants to commit to maintaining something like this we'd love to that but we as vcpkg maintainers are probably ill equipped to address the customers targeted with ${include_dest}.

One problem I've had since this was created (by some external contributor) is that it's named ms-quic instead of msquic (which is the real name of the project, and likely the one people would actually look for). Is there a way to get this fixed?

#39500 fixes this