Dependencies should be part of your repo

[jerkstorecaller]

I'd like to build this tool for my Ubuntu 20.04 system on arm64 (aarch64), but it's not worth the effort.

So the tool requires 3 libraries to build. Where are they? They're not git submodules, even though I bet they should've could've embedded them easily into your repo as submodules and made people who check out your repo able to build it without wasting their time going on a treasure hunt. That's what submodules are for.

Option 2, if you don't want to learn git submodules, is trivial: just dump them in a 3rdparty/ subdir.

Option 3, if you're not happy with any of the above, could be to fetch them as part of CMake. I know of a few C++ devs who gave up on C++ ever having a decent/standard package manager, and who fetch+build dependencies when you run cmake.

Anyway, I read this CMakeLists file, and your dependencies are so obscure, Ubuntu doesn't have them, which means Debian doesn't have them, or any of the Ubuntu derivatives. That's like 80% of all Linux desktop users right there! If I thought you had reason to embed your deps before, man, does this cement it.

Anyway, I ended up losing interest. I dont want to spend 30 minutes installing 3 libraries from source (and likely have to install THOSE libraries' dependencies manually) just to satisfy my curiosity about some random tool I clicked on HN at 2AM.

I know C++ is a language with an ecosystem that's still struggling to enter the year 2000, but you should try to make it easier on users.

Also, today I learned C++ has yet another package manager, Speck. C++'s already struggling with 3 or so package managers competing for relevancy, at a time it absolutely needs 1 to succeed and all others to drop dead. And yet, someone out there decided C++ needed another package manager. And someone else thought they oughta use it over the less unpopular more popular alternatives Conan or vcpkg. "year of usable C++" is starting to sound like "year of the Linux desktop" :P

I probably could've built the tool in the time it took me to write this, but felt I would explain why I didn't, partially to give you the perspective of the average user (and believe me, they are as lazy as I am, if not more, since they wouldn't bother writing this post ), but tbh mostly because mocking C++ is a more fun task to do at 2AM than installing random libraries.

Anyway, remember the golden rule: your project should be buildable by running a single command. Your dependencies aren't PostgreSQL, it's OK to embed a 3000 lines of C++ into your repo.

[haampie]

Hey there. Thanks for opening an issue. In the original release I had a combination of options 1, 2 and 3: https://github.com/haampie/libtree/tree/v0.1.0/deps the runtime deps were either submodules or included verbatim, and the test library was downloaded as part of cmake. People from the Arch linux community requested that external versions of everything could be used, because they have all dependencies in the AUR already, and someone contributed the required cmake changes for that.

In the end I felt uncomfortable vendoring dependencies for various reasons (licensing, source mirroring, pinned versions), so I decided to go for external dependencies only, and use Spack to manage dependencies

because, as you mention, you don't want to do this by hand.

If you do want to do this by hand, note that there's a package-manager-free build description here: https://github.com/haampie/libtree/blob/master/.github/workflows/test.yml

Finally, I'm in the process of rewriting this library in C, exactly so that it's trivial to install: https://github.com/haampie/libtree-in-c this is a work in progress.

[Khoyo]

People from the Arch linux community requested that external versions of everything could be used, because they have all dependencies in the AUR already, and someone contributed the required cmake changes for that.

Which is fun as the current version of elfio in the AUR is not built through cmake but autotools, and thus does not include the required elfioConfig.cmake in the installed package.

I'm not sure whose bug it is. Maye libtool should use CHECK_INCLUDE_FILES() instead of find_package(), maybe arch should build elfio with cmake (which would add a cmake build dependency though).

[tgamblin]

Also, today I learned C++ has yet another package manager, Speck. C++'s already struggling with 3 or so package managers competing for relevancy, at a time it absolutely needs 1 to succeed and all others to drop dead. And yet, someone out there decided C++ needed another package manager. And someone else thought they oughta use it over the less unpopular more popular alternatives Conan or vcpkg. "year of usable C++" is starting to sound like "year of the Linux desktop" :P

Spack (https://github.com/spack/spack) is older than either conan or vcpkg, and it's not (just) a C++ package manager. But what should I expect from HN traffic 🤷🏻.

[matthiasdiener]

fwiw, we also have a (binary) version of libtree available in conda-forge: https://github.com/conda-forge/libtree-feedstock