Easy setup / auto update via FetchContent about hunter

[bkotzz]

This seems awesome. Should we do a separate repo in the cpp-pm org? Or add it to the gate repo?

[bkotzz]

Looking through the code, a few points to make:

• FetchContent is from cmake 11. We should add a line in the example to make it clear (cmake_minimum_required)
• The code parses the release notes from the GitHub API. It just means that we need to make sure we always keep the format of the release notes the same (capitals, etc), otherwise parsing fails and potentially everyone who uses this setup’s builds will start to fail as well. We’ve been meaning to add a bot to automatically release each commit with the appropriate message rather than doing everything manually - doing that would nicely complement this feature
• To avoid parsing the release notes, we could get the tar URL directly from the GitHub app response, but it doesn’t have the SHA. On a slightly unrelated note, how important do people really think the SHA is? How often do you download something in your scripts, and really worry about a corrupt download?
• This setup is meant to pull down latest hunter every time a build is run. This has a couple impacts, rather than locking a version of hunter.
  • One is that the default version of packages often changes between releases, so unless you are locking the version of every package you use, builds may pull in new versions of your package and if that new version is API-incompatible your builds can stop working.
  • Another impact is that we (CC: @rbsheth) are pretty sure that the hunter version factors into the cache key for package builds, so if you are using local/remote caching in your builds rather than building all dependencies from source each time, using the latest version of hunter each time will effectively make your caches useless without a more sophisticated setup
  • I noticed you allow people to lock both package and hunter versions, I’m just mentioning the consequences if someone doesn’t
• Once we have a consensus on what repo to use, I’ll make it. My only lean towards using gate is that our mantra of telling everyone to copy and paste gate into their repo to use hunter feels a bit dirty - it’s not really clear where the code comes from, what version it’s at or how to update it. If we put it in gate we can update the docs to encourage everyone to use FetchContent to bring in gate, and then optionally use this simplified setup above. Eventually maybe we just roll HunterGate and SetupHunter into one

[cristianadam]

I think:

set(HUNTER_PACKAGES package1 package2)

include(FetchContent)
FetchContent_Declare(SetupHunter GIT_REPOSITORY https://github.com/cpp-pm/setup.git)
FetchContent_MakeAvailable(SetupHunter)

would be easy to remember 😄

Edit: I think the gate repo should also be OK. A character less to type.

[chfast]

I'm slightly in favor of setup or init. BTW, you can omit .git suffix in the URL.

[cristianadam]

I'm slightly in favor of setup or init. BTW, you can omit .git suffix in the URL.

I didn't know about the .git suffix omission. Thanks. I've updated the SetupHunter documentation.

I also prefer setup or init, but if the code goes into gate in the CMakeLists.txt instead of doing:

file(
  DOWNLOAD https://raw.githubusercontent.com/cpp-pm/gate/master/cmake/HunterGate.cmake
  ${CMAKE_BINARY_DIR}/HunterGate.cmake)

it could just be:

include(cmake/HunterGate.cmake)

Which should save some KiB from being transferred every time the user runs CMake on the project.

[cristianadam]

I pushed a MR to the gate project cpp-pm/gate#2

I've used the tagged version to download the tar.gz file, and used the downloaded tar.gz file to compute a SHA1 value and feed the file as file:// URL to HunterGate 😄