5 ms·

I really recommend people look into using Hunter to manage CMake dependencies. It's just a much more correct solution than the alternatives b/c your code and al

by geokon 6y ago

I really recommend people look into using Hunter to manage CMake dependencies. It's just a much more correct solution than the alternatives b/c your code and all your dependencies get built reproducibly with the exact same toolchain file. You also get things like namespaces and you eliminate weird issues with multiple versions of dependencies I've compared it to other alternatives (though I wrote this ages ago and it needs an update): https://geokon-gh.github.io/hunterintro.html https://geokon-gh.github.io/hunterintro.html I haven't used vcpkg - but the fact it's forcing its own toolchain file is a huge red flag. CMake is actually really not bad as long as you stick to a subset of the language (ha! sounds like C++) and just don't deal with the whole installer side of things and generator functions. That said 99% of CMake files are written incorrectly. CMakeLists.txt should be system agnostic and compiler/toolchain agnostic. It just coordinates the linking of libraries and where to find headers. All system specific magic needs to be in the toolchain files. Once you break that rule things quickly spin out of control and you get crazy CMake configuration that are a nightmare to maintain

dgellow 6y ago
> That said 99% of CMake files are written incorrectly. I see this repeated over and over since years. At some point if everybody is doing it wrong, either the tool is the actual issue, or there is a clear problem of miscommunication somewhere.
- MaxBarraclough 6y ago
  In CMake, there are many ways to do it, most of them deprecated, and most of them poorly documented. If I recall correctly, even the official Find... modules rely on deprecated functionality.
- bluGill 6y ago
  In any long lived project eventually you discover a better way and regret the past. New tools that don't have a history don't have this problem, but new tools eventually become old and have some dark corner they regret.
lasagnaphil 6y ago
Package managers like Hunter are no use for me if external dependencies that aren’t in the package manager registry (which is typical for my field) can’t be integrated easily. This is precisely the problem your blog post describes at the end.
- geokon 6y ago
  Yeah, that's the part I need to update :) It looks kinda intimidating but it actually ended up being not bad at all. The Hunter docs are just not great unfortunately. They're similar to the CMake docs - very terse and to the point and they totally make sense once you already know everything Basically you just fork Hunter and add your own package with it's own URL and hash and then it works. Just take a look at how the other packages are organized and it'll quickly make sense. You point your project at your fork instead of the "official" Hunter repo and voila. I ended up having to do it for a couple packages and there was no problem I think there was a bit of a mental block for me at first b/c it feels like you will need to "maintain" your own fork. But this is dependency management - there is fundamentally no maintenance. You only update things when you decide to update dependencies. This is always a manual and deliberate process. It's just like how your Hunter version doesn't just magically grab the latest version of Hunter. It's also pinned to a certain release version number The system is very well thought out..

by geokon 6y ago

dgellow 6y ago

> That said 99% of CMake files are written incorrectly. I see this repeated over and over since years. At some point if everybody is doing it wrong, either the tool is the actual issue, or there is a clear problem of miscommunication somewhere.

MaxBarraclough 6y ago
In CMake, there are many ways to do it, most of them deprecated, and most of them poorly documented. If I recall correctly, even the official Find... modules rely on deprecated functionality.
bluGill 6y ago
In any long lived project eventually you discover a better way and regret the past. New tools that don't have a history don't have this problem, but new tools eventually become old and have some dark corner they regret.

lasagnaphil 6y ago

Package managers like Hunter are no use for me if external dependencies that aren’t in the package manager registry (which is typical for my field) can’t be integrated easily. This is precisely the problem your blog post describes at the end.

geokon 6y ago
Yeah, that's the part I need to update :) It looks kinda intimidating but it actually ended up being not bad at all. The Hunter docs are just not great unfortunately. They're similar to the CMake docs - very terse and to the point and they totally make sense once you already know everything Basically you just fork Hunter and add your own package with it's own URL and hash and then it works. Just take a look at how the other packages are organized and it'll quickly make sense. You point your project at your fork instead of the "official" Hunter repo and voila. I ended up having to do it for a couple packages and there was no problem I think there was a bit of a mental block for me at first b/c it feels like you will need to "maintain" your own fork. But this is dependency management - there is fundamentally no maintenance. You only update things when you decide to update dependencies. This is always a manual and deliberate process. It's just like how your Hunter version doesn't just magically grab the latest version of Hunter. It's also pinned to a certain release version number The system is very well thought out..