search

microsoft / vcpkg

C++ Library Manager for Windows, Linux, and MacOS
MIT License
23.16k stars 6.39k forks source link

[vcpkg-tool] HTTPS client integration #19436

Closed SamuelMarks closed 2 years ago

SamuelMarks commented 3 years ago

Is your feature request related to a problem? Please describe. I started https://github.com/microsoft/vcpkg-tool/pull/149 to help resolve #19378. But there is not HTTPS client in vcpkg-tool. (system calls to a curl executable don't count)

Proposed solution We could depend on libcurl. But I assume you've already dismissed that option. So I forked two MIT-licensed cross-platform C repositories, adding CMake—and C89—support to both:

The second solution also depends on OpenSSL. So keeping to the assumption that it's a dependency thing stopping you from adding an HTTPS client to vcpkg-tool, then OpenSSL can be replaced with Common Crypto (macOS), Secure Channel (Windows), and OpenSSL compatible variant on other operating systems.

Describe alternatives you've considered As you can see from my stubs in that aforementioned PR, an obvious alternative can be devised using curl and jq. Windows Batch and sh shell files can be written using these; or it can be hacked together like the other vcpkg-tool code which calls curl from the system.

Additional context I suppose an alternative would be to breathe some life into my old libacquire project (which I suppose is most similar to the previous netw solution).

Anyway adding this issue as an RFC before I spend too much longer going down a path you may not consider favourably…

BillyONeal commented 2 years ago

We could depend on libcurl. But I assume you've already dismissed that option.

No, that option was not considered because we didn't have a binary release, so that would have forced people to build curl in addition to building vcpkg in a relatively hot dev-inner-loop, and we didn't want to inflict external dependencies on people like that.

Now that we have binary releases for all the Important platforms just linking with libcurl is probably the correct solution.

SamuelMarks commented 2 years ago

and we didn't want to inflict external dependencies

Then my libacquire project may be useful, which uses libfetch on FreeBSD, ftp on OpenBSD, WinINet on Windows, and libcurl everywhere else.