[nghttp2-asio] Add nghttp2-asio port

[m8mble]

The nghttp2_asio library was formerly part of nghttp2 but by now is distributed as separate library. Add a port for this library.

• 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. (Note: It doesn't exist, but it's accurate.)
• 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.

[m8mble]

@microsoft-github-policy-service agree

[m8mble]

Could someone explain to me how I can read the error logs?

[Cheney-W]

Could NOT find Boost (missing: thread) (found suitable version "1.81.0",
  minimum required is "1.54.0")

You could get all of the error logs from https://dev.azure.com/vcpkg/public/_build/results?buildId=85548&view=artifacts&pathAsName=false&type=publishedArtifacts

[m8mble]

Thanks for the review.

Apparently the library isn't supported on windows (yet).

• I can attempt to fix it via patches. Is it ok to do so here (on your CI resources via patches)?
• Or should I just disable the new port on windows? (Is "supports": "!windows", in vcpkg.json the right way to do that?)

[Cheney-W]

If the upstream does not support window itself, we can add "supports": "!windows" into the vcpkg.json file. Otherwise, we should use the first solution to fix it.

[m8mble]

I fixed all compile errors. Some errors "unresolved external symbol" remain when linking dynamically on windows. Most needed symbols come from OpenSSL. I have OpenSSL LIBS='optimized;D:/installed/x64-windows/lib/libssl.lib;debug;D:/installed/x64-windows/debug/lib/libssl.lib;optimized;D:/installed/x64-windows/lib/libcrypto.lib;debug;D:/installed/x64-windows/debug/lib/libcrypto.lib'. Is that correct?

I'm not an expert for windows and could use some help here.

[dg0yt]

I have OpenSSL LIBS='optimized;D:/installed/x64-windows/lib/libssl.lib;debug;D:/installed/x64-windows/debug/lib/libssl.lib;optimized;D:/installed/x64-windows/lib/libcrypto.lib;debug;D:/installed/x64-windows/debug/lib/libcrypto.lib'. Is that correct?

AFAICS the package is using CMake. So the natural way to deal with an OpenSSL dependency is find_package(OpenSSL), and link against the provided targets. No Windows know-how needed for this.

There seem to be too many modifications. In particular, I don't see why there is a need to have three add_library when one is enough for vcpkg (without SHARED, STATIC or OBJECT).

[m8mble]

I disabled the port for windows. I have a patch for windows but it would need manual testing. Supporting uwp is likely impossible, since boost-asio doesn't support it.

I've added a dependency of nghttp2-asio[tls] on boost-asio[ssl]. Please review this is correct.

[talregev]

Thanks for the review.

Apparently the library isn't supported on windows (yet).

• I can attempt to fix it via patches. Is it ok to do so here (on your CI resources via patches)?
• Or should I just disable the new port on windows? (Is "supports": "!windows", in vcpkg.json the right way to do that?)

I think it also nice if you can make a PR in upstream to fix windows compilation.

[m8mble]

Agreed. I already did that in #13.

[dan-shaw]

In general, static and shared libraries should be named the same. This will allow consumers of this library to use a common name. Also as @dg0yt pointed out, I don't think we need that many add_library calls as the library linkage is inferred from BUILD_SHARED_LIBS.

[m8mble]

I agree, I can patch with a smaller diff. I just used the very same change that I already submitted upstream. But you are right that this arguably adds more features than strictly necessary.

Please note though, that the library files (not cmake libraries) have identical basenames.

Do you prefer the single add_library call or could the patch be merged as is?

[dg0yt]

What will upstream decide?
When will be the next release?

[m8mble]

I don't know. I'm not a maintainer. Upstream has been pretty quiet lately, no releases so far.

Would you prefer a smaller patch?

[dg0yt]

I don't know what upstream wants. But vcpkg doesn't need Support linking both statically and shared during the same build. This is popular with autotools build systems, but it is sort-of an anti-pattern for CMake build systems, at least as used in vcpkg: You have to add more CMake code everywhere, for cases which could be switched with the standard BUILD_SHARED_LIBS.

[m8mble]

Alright, no worries. I'll provide a simpler patch.

[vserdyuk]

I think it also nice if you can make a PR in upstream to fix windows compilation.

I tried to upstream my fixes for building dynamic library with MSVC + building static library on macOS and Linux, nobody seemed to be interested:
nghttp2/nghttp2#1615

[talregev]

Don't worry. maybe it take time. If not, we move forward.