[libcurl-simple-https] New port

[SamuelMarks]

Describe the pull request

Very simple HTTPS interface built atop libcurl

https://github.com/SamuelMarks/curl-simple-https

• What does your PR fix?

• Which triplets are supported/not supported? Have you updated the CI baseline?

All

• Does your PR follow the maintainer guide?

Yes

• If you have added/updated a port: Have you run ./vcpkg x-add-version --all and committed the result?

Yes

If you are still working on the PR, open it as a Draft: https://github.blog/2019-02-14-introducing-draft-pull-requests/

Possibly still a draft, need to see what your CI says

[SamuelMarks]

Actually don't merge this yet, getting weirdness on the find_package end. Without find_package it links fine with my package (cauthflow). With find_package(libcurl-simple-https CONFIG REQUIRED) I get:

Could not find a package configuration file provided by
  "libcurl-simple-https" with any of the following names:

    libcurl-simple-httpsConfig.cmake
    libcurl-simple-https-config.cmake

Even though:

vcpkg (project0) $ fd -HIFecmake 'libcurl-simple-httpsConfig'
buildtrees/libcurl-simple-https/x64-osx-dbg/libcurl-simple-httpsConfig.cmake
buildtrees/libcurl-simple-https/x64-osx-dbg/libcurl-simple-httpsConfigVersion.cmake
buildtrees/libcurl-simple-https/x64-osx-rel/libcurl-simple-httpsConfig.cmake
buildtrees/libcurl-simple-https/x64-osx-rel/libcurl-simple-httpsConfigVersion.cmake

(and it found my other vcpkg dependencies, it's just this package…)

[dg0yt]

set(CMAKE_FIND_DEBUG_MODE 1)

[SamuelMarks]

@dg0yt Ok thanks… so with that enabled I was able to find that manifest mode is the issue. I have a vcpkg.json in my root.

With manifest mode enables I still get this:

The package libcurl-simple-https provides CMake targets:

    find_package(libcurl-simple-https CONFIG REQUIRED)
    target_link_libraries(main PRIVATE libcurl-simple-https libcurl-simple-https_compiler_flags)

(even double checked by ./vcpkg remove libcurl-simple-https first from my vcpkg root)

However fd -HIFecmake 'libcurl-simple-httpsConfig' shows nothing from my project root (only shows in my vcpkg root when I ./vcpkg install libcurl-simple-https)

What am I doing wrong? - E.g., this line of my CMakeLists.txt:

install(EXPORT "${LIBRARY_NAME}Targets" DESTINATION "share/${LIBRARY_NAME}")

[dg0yt]

I am unable to follow. Maybe it is too early to integrate into vcpkg.

[SamuelMarks]

@dg0yt Possibly. Anyway this project is the simplest non-header-only C89 CMake project I have. So once this issue is resolved then you'll see a lot more [& working] ports being contributed from me.

There are two CMakeLists.txt one .c and one .h, along with a vcpkg.json:

|-- CMakeLists.txt
|-- libcurl-simple-https
|   |-- CMakeLists.txt
|   |-- curl_simple_https.c
|   `-- curl_simple_https.h
`-- vcpkg.json

Everything else is boilerplate, primarily from the official CMake tutorial.

Why is this failing? - Thanks for any insight

[dg0yt]

Anyway this project is the simplest non-header-only C89 CMake project I have. So once this issue is resolved then you'll see a lot more [& working] ports being contributed from me.

C89 seems to be quite the opposite direction to modern C++. I have no benefit from the fact that a package supports this old standard.
And ports which are working now are still a technical debt when updating their dependencies. (And I did work on port curl.)

Everything else is boilerplate, primarily from the official CMake tutorial.

No, it isn't. It does a lot of non-standard things. (Hint: Many relevant lines contain "${PROJECT). To be fair, many CMake projects are more complex than necessary.

along with a vcpkg.json

Assuming that we talk about building the port, remove it (with a command in the portfile).
Check the logs for what is build and installed, and where to.

[SamuelMarks]

For reuse as boilerplate across my decent number of C projects, I took https://gitlab.kitware.com/cmake/cmake/-/blob/master/Help/guide/tutorial/Complete and:

• replaced literal names with variables;
• removed functionality irrelevant to my purposes;
• added stronger use strict style guards:
  • set(CMAKE_C_STANDARD 90)
  • set(CMAKE_C_VISIBILITY_PRESET hidden)
  • set(CMAKE_VISIBILITY_INLINES_HIDDEN YES)
  • "$<${gcc_like}:$<BUILD_INTERFACE:-Wall;-Wextra;-Wshadow;-Wformat=2;-Wunused;-pedantic>>"
  • "$<${msvc}:$<BUILD_INTERFACE:-W3;-WX;-Zi;-permissive->>"
• generated export headers with GenerateExportHeader;
• set separate Source_Files and Header_Files vars [with source_groups] for installation [and IDE assist]

Following your advice @dg0yt from the #22930 pull request I added the aforementioned INSTALL(EXPORT line.

I'm going to try without manifest mode and see how far I get…

Any other tips would be greatly appreciated

[dg0yt]

Personally I think packages should have some relevance before being accepted into the main repo.

[sfhacker]

Perhaps someone has requested this addition.

[SamuelMarks]

It's a convenient interface to libcurl?

Even this month this was posted https://daniel.haxx.se/blog/2022/02/02/curl-dash-dash-json

So it's not like they aren't thinking about it [officially]…

[mathisloge]

Personally I think packages should have some relevance before being accepted into the main repo.

think so too. Such just-created projects are often abandoned by the maintainer and are then in the official repo and carry a lot of dept. Especially when you consider that everything always has to be built, projects that are possibly only used by one person or no one can disrupt an important library such as curl in the update process. IMHO those are good candidates for custom registries. #17540 (comment)

[SamuelMarks]

First commit: Jul 23, 2021

Albeit not used by projects I'm not involved in, but this is a dependency for:

• cauthflow
• bunch of internal projects
• google-cloud-c

If there was some better metric for acceptance, happy to follow. E.g, a certain level of test and documentation coverage, cross-platform support, &etc.

[mathisloge]

This is just my personal opinion and not specific to this project.
But all these projects you list belong to your own organisation and would work even if they were used in a custom registry, and this will not prevent anyone from using your projects either. and if, for example, you realise at some point that you no longer want to support them, that's no problem either, because they don't have to be maintained in the vcpkg universe.

But yeah. This is a decision of the vcpkg team.

[SamuelMarks]

Yes you are right that these would all work just fine in a custom registry. But that's not my question. My question is what metrics do you use to decide betwixt the two?

The primary advantages of having them in vcpkg itself are: review by vcpkg staff; CI access; advertising (when I was looking for UI frameworks I used grep and ls on your ports tree to find them). So would be good not to lose these advantages.

Metrics which might be what you're looking for to decide whether to accept them into vcpkg are, from the top of my head:

• Cross-platform support;
• Cross-architecture support (esp. for Windows);
• Open-source license (and which one);
• Test coverage;
• Documentation coverage.

Fluffier metrics like number of tweets, blogposts, GitHub stars and the like are all gameable… so would prefer to stick to more objective measures (assuming you'd be open to that).

[mathisloge]

I think it would be good to have a metric for survivablity.
E.g. How likely is it, that the project would be maintained in the future.
So:

• founded support of companies
• number of contributors
• stars could very well be a guidance: if the maintainer sometime decide to not support the project, some of those stargazers might jump in. So the likelyhood of survival is a bit better

Test coverage etc. are not that indicative IMHO since those need to be analyzed very closly to say anything about the quality of the coverage.

But I do understand your argument of the visibilty. And there should be some discovery mechanism provided by vcpkg to list available custom registries.

[dg0yt]

The primary advantages of having them in vcpkg itself are: review by vcpkg staff; CI access; advertising

I do understand the advantages on your side. But I also see that your PRs consume limited review capacity, even solving "upstream" (i.e. your) problems with plain CMake project which are entirely unrelated to vcpkg. In the meantime I wait days and weeks for reviews, have to re-explain basics, and re-resolve merge conflicts. So your benefits come at a price.
And I all I want that there is a conciousness for these side effects.