Git submodules are definitely a hack. My experience with conan has been unpleasant for several reasons, but mostly in regards to writing dependencies for code bases that use submodules and aren't interested in my team's suggestion they use conan. Vcpkg doesn't seem better, and probably a bit worse. Does hunter make this any easier?
If the dependency you want to use has no dependencies of its own - then it can be used directly with no changes (as long it's CMakeLists.txt is sane and it can use a passed-in toolchain file)
If the dependency has its own dependencies, then you need to "Hunterize" it - specify library versions, tweak the targets to use namespaces, etc. They're usually small changes. They have a huge list of Hunterized forks:
A minimal CMakelists.txt will look something like:
HunterGate(
URL "https://github.com/cpp-pm/hunter/archive/v0.23.297.tar.gz"
SHA1 "3319fe6a3b08090df7df98dee75134d68e2ef5a3"
)
project(Foo)
hunter_add_package(Boost COMPONENTS regex system filesystem)
find_package(Boost CONFIG REQUIRED regex system filesystem)
add_executable(foo foo.cpp)
target_link_libraries(foo PUBLIC Boost::regex Boost::system Boost::filesystem)
The first block specifies the available package list (you can fork and host your own). If you disable Hunter this isn't used
The line that reads `hunter_add_package` is the Hunter part that downloads and build the dependency (using the current toolchain file). But if you disable Hunter then that line would simply get skipped.
In the third line `find_package` will run.. and if you had Hunter build the dependency then it'd use that as the target - otherwise it just runs like "normal CMake" and it tries to find the package elsewhere (like from your system package manager or whatever)
If your dependency has its own dependencies as git submodules.. then I'm not super sure you have a very clean migration path b/c they will not be using `find_package` and will instead be using `add_subdirectory`. Maybe you could patch their CMakeLists.txt to use Hunter when explicitely enabled, and then drop down to `add_subdirectory` otherwise. It'd be a bit ugly but they would keep their workflow I guess. You'd need to check that their targets end up with the same namespaced names (with the :: notation) when seen from your project... I don't know off the top of my head how Hunter handles a subdirectory with a project name of it's own
Sorry I wasn't clear. I was responsible for the dependency that another team was using as a plugin. They weren't going to switch to conan, and our code was already using Conan for itself and its dependencies. They wanted to bring us in as a submodule, and that was just never going to work. I think what I'm pulling out of this thread is that c++ package management is so fragmented, there isn't really a safe choice to ensure you can use or be used by people who made other choices.
Oh okay - I think in that case it's possible Hunter would solve your problems. If you rewrite your library to use Hunter, then when it gets pulled in with add_subdirectory(), it should just build and get it's dependencies with Hunter - all from within CMake itself. No external tool necessary (the Hunter functions are defined in the project root `.cmake` file)
I don't see any reason that wouldn't work - but.. you'd have to test it. I've never tried running a Hunterless top-level project with a Hunter-ized subdirectory. The top level project would still get some benefits like the namespaced targets (so you won't clobber anything in top-level)
The only small catch is that Hunter inevitably does build a cache of build artifacts/targets for your dependencies. As long as you keep using the same toolchain files these keep getting reused each time you rebuild your project. That does however mean you will get some user folder like ~/.hunter with those build artifacts (look at the Hunter config options.. maybe this can be somehow hidden in the build directory?). I dunno if that would irritate the project users. If it's company internal that's probably an okay ask. If it's random devs on github then that's a bit not-nice :)
Thanks! That looks like it might be fine. The conan cache works the same way but all our builds and deployments are containerized so the ~/.conan wasn't the issue, it was that conan was in control, not cmake.
