3 ms·

--- While your point is completely fair in that 24 packages won't make a very useful service, it's also fair to say this is a new tool and it's OK to give it so

by mdip 8y ago

--- While your point is completely fair in that 24 packages won't make a very useful service, it's also fair to say this is a new tool and it's OK to give it some time. --- (EDIT: for the sake of transparency, I'm crossing out this initial paragraph since, after reading some other comments, I've discovered that cppget isn't all that new; the rest of my comment, however, is relevant without that statement) I'll poke a little at your assertion that it's "never the build tool itself". Unfortunately, in my experience, it often is. Have a nice fight with Hunter in a project or two. It's got a decent, though still somewhat small, number of packages[0], but that doesn't make it useful. Every time I reload my PC and clone the two repos that rely on it, I invariably spend a day sorting out something or another (last time it was signature related). It doesn't help that the tool is tied to CMake, these are the only two repos I use that rely on CMake and I have actively avoided learning enough about it to not require several Google searches when I need to do somewhat simple things, but that's the rub. Cargo is simple, even npm (by comparison) is simple even for projects with great complexity[1]. Hunter, by comparison, has me asking every single time I have to update a dependency or install fresh from a clone ... what problem is this solving for me? How is this less manual than managing dependencies with a clever zsh script[2]? As far as vcpkg is concerned, I agree, though I'm a Microsoft fan[3]. It generally works -- and unlike Hunter, which uses CMake as well, I haven't run into the kind of hair pulling, four-letter word spewing fits using it ... at least not to the extent that I did. To the authors: Really, though, please please keep investing in making better dependency management tooling. If it's good enough, there are enough of us that will make "unofficial packages" because it takes less time to figure that out than it does to figure out how to fix the broken dependency management system we're stuck with. [0] https://docs.hunter.sh/en/latest/packages/all.html https://docs.hunter.sh/en/latest/packages/all.html [1] I'm certainly not saying it's not without its pointy corners, but I'll take those sharp edges any day over some of the C++ build tools I've played with. [2] Which is the only "build dependency management" system that's worked for me -- I literally "lynx --dump" the releases page, parse for URLs, download and script out each build dependency manually ... I even have a set of functions that manage to do some of this in a relatively well abstracted manner given the circumstances. Granted, these are single platform target apps, but so are the handful I have that use vcpkg. [3] Well... to be fair, my one Windows 10 install is in a virtual on an openSUSE Tumbleweed installation, so maybe I'm not a fanboy, but with their movement towards open sourcing a lot of their tooling and frameworks, there's not a lot I can complain about, personally.

geokon 8y ago
I don't quite get what issue you had with Hunter, thought if you actively try to not learn the standard tool - CMake, then you're gunna have problems... It works flawlessly for me. I literally clone a repo, give it the corresponding toolchain file and it builds everything from the ground up on any system instantly. I really feel the C++ dependency issue has been resolved conclusively I just wish Hunter was part of CMake by default b/c CMake should be able to load other CMake projects and resolve dependencies. It itself has all the information internally to make this really easy - ie. targets, interfaces and dependencies. Handling this from outside of CMake is just a much harder problem and you end up having to restate a lot of what's already in the CMakeLists.txt. ExternalProject_Add() is a giant footgun that should have never been part of CMake - I wrote a little description of why here: https://geokon-gh.github.io/hunterintro.html https://geokon-gh.github.io/hunterintro.html There are two outstanding issues: - if you need to link to proprietary libs then the rebuild-everything-from-scatch strategy is deficient - but then things are going to get messy anyways.. - if libA links to libBv1 and libC links to libBv2, then there is no clean way to link both libA libB and libC in to an application. Usually libraries aren't too picky about which version you link - but there is always a chance things will blow up in your face. This is probably going to be solved with flatpaks runtimes or something like that
- mdip 8y ago
  ...And your point is fair - a lot of the difficulty to me comes from fighting with CMake, which, due to the fact that I don't support a large number of applications that rely on it is a piece of technology that I don't retain enough knowledge on when I end up having to use it to be particularly strong at working with. I remember one of the most frustrating incidents that I had with Hunter was, indeed, a CMake issue of my own (well kind-of) causing. On a one-off machine I was running a build on, I was getting signature failures every time Hunter went to download code. I checked everything (and, of course, there were signature-related things that looked like they might be a problem but probably weren't). It turned out that the cmake binary on this host was not compiled with SSL support. I guess the folks who wrote error messages for earlier C++ compilers wrote error messages for Hunter/CMake, because at no point did any error offer any hint about the binary lacking SSL and it wasn't until I decided to download the source code to the latest CMake (because the packaging system I was using didn't have the latest). I can't remember the completely specifics (i.e. if hunter/cmake relied on cURL and it was libcurl/curl itself lacking SSL support), but I remember I happened upon the solution by accident while reviewing the compiler flags of the current version of the installed bits to figure out what to use to build the latest version and I realized that the URL to the dependency was https and there was no way that was going to work without the --enable-whatever flag required to support TLS :). So yes, it's possible I am or have been blaming hunter when I should be blaming cmake, or more accurately, my lack of knowledge in using both tools. At the same time -- and I know this is a really unfair comparison -- I support very few things in Python or node, however, the grief I encounter when I return to that tooling is minimal. It requires a lot less out of me to get things working even in complex applications.

by mdip 8y ago

geokon 8y ago

I don't quite get what issue you had with Hunter, thought if you actively try to not learn the standard tool - CMake, then you're gunna have problems... It works flawlessly for me. I literally clone a repo, give it the corresponding toolchain file and it builds everything from the ground up on any system instantly. I really feel the C++ dependency issue has been resolved conclusively I just wish Hunter was part of CMake by default b/c CMake should be able to load other CMake projects and resolve dependencies. It itself has all the information internally to make this really easy - ie. targets, interfaces and dependencies. Handling this from outside of CMake is just a much harder problem and you end up having to restate a lot of what's already in the CMakeLists.txt. ExternalProject_Add() is a giant footgun that should have never been part of CMake - I wrote a little description of why here: https://geokon-gh.github.io/hunterintro.html https://geokon-gh.github.io/hunterintro.html There are two outstanding issues: - if you need to link to proprietary libs then the rebuild-everything-from-scatch strategy is deficient - but then things are going to get messy anyways.. - if libA links to libBv1 and libC links to libBv2, then there is no clean way to link both libA libB and libC in to an application. Usually libraries aren't too picky about which version you link - but there is always a chance things will blow up in your face. This is probably going to be solved with flatpaks runtimes or something like that

mdip 8y ago
...And your point is fair - a lot of the difficulty to me comes from fighting with CMake, which, due to the fact that I don't support a large number of applications that rely on it is a piece of technology that I don't retain enough knowledge on when I end up having to use it to be particularly strong at working with. I remember one of the most frustrating incidents that I had with Hunter was, indeed, a CMake issue of my own (well kind-of) causing. On a one-off machine I was running a build on, I was getting signature failures every time Hunter went to download code. I checked everything (and, of course, there were signature-related things that looked like they might be a problem but probably weren't). It turned out that the cmake binary on this host was not compiled with SSL support. I guess the folks who wrote error messages for earlier C++ compilers wrote error messages for Hunter/CMake, because at no point did any error offer any hint about the binary lacking SSL and it wasn't until I decided to download the source code to the latest CMake (because the packaging system I was using didn't have the latest). I can't remember the completely specifics (i.e. if hunter/cmake relied on cURL and it was libcurl/curl itself lacking SSL support), but I remember I happened upon the solution by accident while reviewing the compiler flags of the current version of the installed bits to figure out what to use to build the latest version and I realized that the URL to the dependency was https and there was no way that was going to work without the --enable-whatever flag required to support TLS :). So yes, it's possible I am or have been blaming hunter when I should be blaming cmake, or more accurately, my lack of knowledge in using both tools. At the same time -- and I know this is a really unfair comparison -- I support very few things in Python or node, however, the grief I encounter when I return to that tooling is minimal. It requires a lot less out of me to get things working even in complex applications.