14 ms·

I hope one day we can get a widely adopted C and C++ package manager. The friction involved in acquiring and using dependencies with odd build systems, etc. is

I hope one day we can get a widely adopted C and C++ package manager. The friction involved in acquiring and using dependencies with odd build systems, etc. is one of the things I dislike about the language. I’m aware on Linux things are a bit easier, but if it were as easy as “npm install skia”, etc. everywhere, I think many people would use the language more. Rust has package management, but not the ecosystem yet. On the other hand, C/C++ has the ecosystem, but no standard way to easily draw from it.

dgellow 6y ago
Have you tried vcpkg? https://github.com/Microsoft/vcpkg https://github.com/Microsoft/vcpkg It's a tool to manage C++ dependencies (using CMake), created and maintained by Microsoft. A lot of open source projects are supported (you can see part of the list here: https://github.com/microsoft/vcpkg/tree/master/ports https://github.com/microsoft/vcpkg/tree/master/ports).
- Const-me 6y ago
  I did, about a year ago. The usability was questionable. Their main workflow appears to be, all developers use that thing, everyone building packages from source code and using their own binaries. For large dependencies that’s a large waste of time if more than 1 person is working on the software. It’s possible to export built libraries as nuget packages, but these are tricky to consume. Another thing, these ports (where they applying patches to third party open-source code to squeeze them into vcpkg) are fragile. I remember cases when packages didn’t build, either at all, or subject to conditions (half of what I tried was broken when I only wanted release configurations).
  - dgellow 6y ago
    I believe that's a recent development but vcpkg has decent binary caching now: https://github.com/microsoft/vcpkg/blob/master/docs/users/binarycaching.md https://github.com/microsoft/vcpkg/blob/master/docs/users/bi.... Edit: they also have an experimental support for registries since February of this year: https://github.com/microsoft/vcpkg/blob/master/docs/specifications/registries-2.md https://github.com/microsoft/vcpkg/blob/master/docs/specific...
  - snarfy 6y ago
    Without a standard ABI, having c++ binary packages is a huge pain, requiring multiple artifacts for every permutation of compiler, os, and platform. It's less painful today than in the past, simply due to fewer compilers, OSes, and platforms, but it is still a problem.
    - Const-me 6y ago
      All developers on that team used 1 compiler (VC++ 2017 at that time), one OS (Windows 10), one target platform (AMD64). Compiler/linker settings are shared across developers. I wanted vcpkg to export just the required artifacts (headers, DLLs, static libraries, and debug symbols), so only 1 person on the team (me) is wasting time building these third-party libraries. The team is remote, upload/download size needs to be reasonable.
      - meragrin_ 6y ago
        I have been using it since at least 2018 to create NuGet packages of dependencies. You can also do zip and others.
    - bluGill 6y ago
      A common ABI doesn't save anything as we still need to build for ARM, and x86 (MIPS, RISCV are also out there and may be important to you). Those processors all have different generations, it might be worth having a build for each variant of your CPUs. Once you take care of that different ABIs are just a trivial extension. RPM and .deb have been able to handle this for years.
  - jcelerier 6y ago
    > For large dependencies that’s a large waste of time if more than 1 person is working on the software. but all other hype languages do this and you don't hear people complaining
    - dgellow 6y ago
      Maybe a difference is that C++ can be very, very slow to build. And C++20 will likely results in even longer build time now that you have concepts and can have exceptions and allocations in a constexpr context.
    - throwaway894345 6y ago
      What's a "hype language"?
      - jcelerier 6y ago
        Rust, Go, Julia, Swift ?
        throwaway894345 6y ago
        What makes them hype languages? Oh, so like new languages?
        jcelerier 6y ago
        > What makes them hype languages? being high in the chart here: https://insights.stackoverflow.com/survey/2020#technology-most-loved-dreaded-and-wanted-languages-loved https://insights.stackoverflow.com/survey/2020#technology-mo...
        throwaway894345 6y ago
        Ah, so hype == love.
        6y ago
vlovich123 6y ago
Widely adopted source code manager requires a widely adopted build system. CMake is certainly a contender but the ecosystem is too fragmented even then & you have to do a lot to try to link disparate build systems together. Also C++ is a transitive dependency hell nightmare & any attempt to solve that (like Rust has) would break every ABI out there. Given how bumpy such breakages have been in the past, I don't think there's any compiler maintainer eager for it (even MSVC has decided to largely ossify their STL runtime ABI). Conan is certainly a laudable attempt at something like this. Without access to their metrics though, it's hard to tell if they're continuing to gain meaningful traction or if their growth curve has plateaued. It's certainly not in use in any project at medium to bigger size companies I've worked at. By comparison, Cocoapods was pretty successful in the iOS ecosystem precisely because Xcode was the de facto build/project system.
- mikepurvis 6y ago
  I'm a longtime CMake user, but I think even within the CMake world, the solution is quite a bit more complicated than just "everything needs to be CMake", with a lot of hassles that arise when multiple generations of the tooling is involved, when you're trying to pass down transitive dependencies, when package X has a bunch of custom find modules with magic to try to locate system versions of dependencies but silently fall back to vendored ones. The higher up the stack you get, the worse and worse these problems get, with high-level packages like Tensorflow being completely intractable: https://github.com/tensorflow/tensorflow/tree/master/tensorflow/lite/tools/cmake/modules https://github.com/tensorflow/tensorflow/tree/master/tensorf...
  - vlovich123 6y ago
    Yup. 100% agree. I totally overlooked the shitshow you'll have managing the different versions of CMake a build might require. Somehow Bazel manages to escape that mess. I think that might be a better foundation, but getting everyone to port to that... it's a tall ask & there's many vocal people who are against improving the build system they work with (hell, I've met many engineers who grumble and strongly prefer Makefiles).
bregma 6y ago
We'd also need the one operating system on the one architecture. Perhaps the central planning committee can make that a goal for their next five year plan?
- mikepurvis 6y ago
  Python, Ruby, Node, Go, and Rust all work on multiple OSes and arches.
  - bregma 6y ago
    Python and Ruby only work on the Python and Ruby interpreters, respectively, and those require an OS-specific way to install them. They work on multiple OSes and architectures as well as JavaScript or HTML. Go and Rust work only on a very very limited set of OSes and architectures. That's fine if you're targeting one of those, but it turns out the vast majority of computers in the world are not vanilla rice-pudding desktop systems or vanilla rice-pudding desktop systems adapted for the server room. The argument that some other tool solves a limited set of problems with your tool in a limited and limiting way is a poor one if you're trying to promote a universal solution.
    - oblio 6y ago
      Java runs on many platforms (and billions of devices as Sun used to love to point out), yet packaging and dependency management are pretty much solved problems. Where there's a will, there's a way. In the C/C++ community there's no will. It's time they admit that to themselves and everyone else.
      - bregma 6y ago
        Java runs only on the Java interpreter. C and C++ run on the bare metal of the CPU. Is Java modeled around a central repository of all dependencies so users can download random binaries off the internet?
        6y ago
pjmlp 6y ago
Just like the sibling comment, I would vouch for vcpkg, although for my use cases NuGET will also do.
oregontechninja 6y ago
I've been using conan pretty easily. My biggest issue is that the recommended install method is via Python's pip
jasode 6y ago
>I hope one day we can get a widely adopted C and C++ package manager. [...] , but if it were as easy as “npm install skia”, etc. everywhere, It's not just the package manager (the command line tool) ... it's the canonical website source that the tool pulls from. C++ probably won't have a package manager with the same breadth of newer language ecosystems like npm/Nodejs and crates.io/Rust because for 20+ years C++ was developed by fragmented independent communities before a canonical repo website funded by a corporation or non-profit was created. There is no C++ institution or entity with industry-wide influence that's analogous to Joyent (Nodejs & npm) or Mozilla (Crates.io & cargo) I wrote 2 previous linked comments about this different timeline: https://news.ycombinator.com/item?id=24846012 https://news.ycombinator.com/item?id=24846012 Tldr, 2 opposite timelines happened: - C++ for 20+ years of isolated and fragmented development groups creates legacy codebases --> then decades later try to create package manager (vcpkg? Conan? cppget?) that tries to attracts those disparate groups --> thus "herding cats" is an uphill challenge - npm and crates.io exist at the beginning of language adoption allowing the ecosystem to grow around those package tools and view them as canonical
- coder543 6y ago
  Go has a perfectly good package manager that works with sources hosted on GitHub and other sites -- there isn't any centralized place for people to publish sources, unlike the other package managers you mentioned. Go's package manager also came years after the language became widely used, and it is now very widely adopted according to the most recent survey[0]. I think C++ could have a good, unified package management story. It would just require the major stakeholders to all care enough to make it happen, which seems to be the missing piece here. [0]: https://blog.golang.org/survey2020-results#TOC_8 https://blog.golang.org/survey2020-results#TOC_8.
  - jasode 6y ago
    >Go's package manager also came years after the language became widely used, and it is now very widely adopted according to the most recent survey[0]. Are you talking about "pkg.go.dev" and the "go get" command? Isn't there some path dependence in the history of events that's not comparable to C++? Consider: - Go language: created by Google Inc - "go get" syntax for package download designed and created by Google Inc - "pkg.go.dev" funded by Google Inc and highlighted on "golang.org" website that's also run by Google Inc. There is no business entity or institution in the C++ world that's analogous to Google's influence for Go + golang.org + "go get" + pkg.go.dev. >It would just require the major stakeholders to all _care_ enough to make it happen, But it's easier to care if there was an influential C++ behemoth that captured everyone's mindshare to move the entire ecosystem forward. C++ has no such "industry leader" that dictates (or heavily influences) technical direction from the top down.
bluGill 6y ago
Rust's package management is actually a downside to my adoption. I have a lot of C++, a home-grown package manager, and a large cmake based build system. Rust wants to replace all this, but that means shelling out to Rust's build system, which is a bit of a messy situation and means I need to learn a new build system with the language. (not hard, but another thing to learn). Our home grown package manager means we have our own local copy of everything - I have a hard requriement to be able to rebuild software for the next 15 years (there is a closet someplace with a windows XP service pack 1 PC so we can build some old software - God only knows if it will boot anymore). In the embedded space we need to support our old code for years, and you can't always upgrade to the latest.
- coder543 6y ago
  "cargo vendor" enables you to embed your entire dependency tree into your repo instantly, and compilation will work from that. Over half of your comment seems to have been predicated on the assumption that this either wasn't possible or wasn't easy... so I think your perceptions of Rust's package management system are more of an impediment to you than the actual package management system.
  - saurik 6y ago
    Oooo... does Rust have a good way to do this with submodules instead of copies?
    - coder543 6y ago
      It sounds like you're implying git submodules are actually a good thing... I think you're the first person who has implied such a thing to me before. Everyone I actually know agrees that submodules are basically never the right solution or a pleasant solution. But, to your question, no. Where would the submodules even point? The dependency source code artifacts are stored "immutably" (except for takedown notices or extreme abuse cases) on https://crates.io https://crates.io. They aren't git repos, and there's nowhere for git to point.
fsloth 6y ago
"I think many people would use the language more" C++ is considered the industry leading language in many fields. I'm not sure how many more you would want (given that those fields that don't use C++ ARE probably better served with some other language). I agree the build is painfull, but large orgs have for this reason specifically implemented build systems using nugets, conan/cmake or whatnot. In personal projects I just download the prebuilt binaries of component libraries and drag and drop them to visual studio, minimizing hassle. If you discard finesse and scalability as requirements you can actually jury rig a C++ project in a jiffy. You just need to let go of the idea that it must be "industry standard setup".
- throwaway894345 6y ago
  C++ used to be the industry leading language in many more fields, but it lost ground to other languages. Not a bad thing--"know thyself" and all that. But Rust seems like a credible threat to C++'s remaining niches (bury your head in the sand if you want), and C++ will need to evolve if it is to not lose further market-/mindshare. And it is evolving, as this article points out, but a huge glaring pain point in C++ development remains the build and package management tooling. The aforementioned build systems that large organizations operate aren't nearly as nice as, say, Cargo and I think a lot of greenfield projects who have to choose between cobbling together their own build tool to work with C++ and using Rust + Cargo off the shelf will choose the latter (other factors notwithstanding).
  - pjmlp 6y ago
    I will get worried when NVidia releases CUDA-Rust, and changes their GPGPUs from C++ memory model to Rust, Microsoft decides to rewrite WinUI in Rust, Apple moves Metal from C++ into Rust, or Unreal/Unity get rewritten in Rust.
    - throwaway894345 6y ago
      Like I said: > bury your head in the sand if you want Great chat, as always. :)
throwaway894345 6y ago
> Rust has package management, but not the ecosystem yet. On the other hand, C/C++ has the ecosystem, but no standard way to easily draw from it. I take your point, and I share your desire for a canonical, Cargo-like package manager and build tool for C++ (it's one of the reasons I pivoted out of C++ development); however, I don't think C/C++ "has the ecosystem" these days. It certainly has an ecosystem--C/C++ dominates its own niches, but there's a big world outside those niches and there aren't good packages for much of it. Meanwhile, Rust is growing like a weed both inside and outside of the C/C++ niches, and the package manager largely enables that rapid growth. Also, Rust has a good interop story for C/C++, allowing it to leverage the existing C/C++ ecosystem. Anyway, I hope this doesn't read as contrarianism--I just thought it was an interesting distinction.
- pjmlp 6y ago
  Most of the places where C++ doesn't have good libraries I wouldn't want to use Rust anyway, that is the domain of managed languages, GUIs, distributed computing, Web development. And for the stuff I use C++ for, COM/UWP, Android NDK, GPGPU shaders, Unreal/Unity, Rust tooling is yet WIP or requires to leave the confort of the existing C++ frameworks and IDE integrations.
  - throwaway894345 6y ago
    I would use Rust for distributed computing and GUIs, and I wouldn't be surprised if it begins to break into the graphics/gamedev world in the next 5 years. Agreed that Rust is still immature in those areas today, but it seems to be on a pretty aggressive trajectory and it's only a matter of time before Rust begins chipping away in those domains. I did some real-time embedded development (including distributed embedded) in a past life in C and C++, and I really expect Rust to break through in that domain in a big way even though it's incredibly conservative (C++ is still the new kid on the block). It will take some time and it's never going to "kill" C or C++ in that domain (especially considering all the hardware that exists that LLVM doesn't yet target), but I think Rust will carve out a swathe of the embedded space for itself.
    - 6y ago
mackal 6y ago
I actually extremely dislike language specific package managers. I'm on Linux, the packages should be in my package manager. I don't want to maintain multiple package managers. nmp is actually the worst here.
- Koshkin 6y ago
  Great point. I think BSDs got this right with their ports. (Incidentally, NetBSD's pkgsrc supports Linux.)
- Ar-Curunir 6y ago
  The Linux model of package management doesn't work for newer languages. In particular it is heavily reliant on dynamic linking, which tends not to work when you have (a) an unstable ABI (b) generics (c) a culture of static linking.
  - beojan 6y ago
    It works fine, you just ship the static libraries. With static linking your binaries won't have dependencies anyway. That's not to say the static linking craze is a good thing. We'd be far better off finding a way to dynamically link templates, so you get the security benefits of automatically updated dependencies that dynamic linking gives you.
- gowld 6y ago
  Code library managers don't belong inside OS package managers (because you want hermetic builds), unless maybe you have some Nix-live multi-manager that can provide many environments.
- quacker 6y ago
  > I actually extremely dislike language specific package managers. I'm on Linux, the packages should be in my package manager. I don't want to maintain multiple package managers. nmp is actually the worst here. As a user of software that doesn't care how it's built, sure. But system package managers are not a solution for general development with C++, or any other language. If I want to use C or C++ to create software, how do I use libraries that aren't available in a system package manager? What if I need a version of a library that's not available in my system package manager? There are answers here but they aren't good answers (build from source, using whichever of N build tools the project happens to use, or hope there are prebuilt libs hosted somewhere) Relying on system package managers to contain dependent libraries makes cross-platform development a complete PITA (more that it already is). Now you need the specific versions of all your libraries in package managers on all platforms, which is a complete non-solution for real development.
flatline 6y ago
Conan is probably the flagship C++ package manager and supports multiple build systems including cmake. Nuget/vcpkg is also usable but does not come with build system integration.
- invokestatic 6y ago
  Vcpkg has great CMake integration. Further, the model of Conan of distributing a bunch of binaries honestly seems like the wrong approach for C++ where you have to juggle all different sorts of compilers, triples, and ABIs. We use a completely custom toolchain which pretty much rules out Conan. The one annoying thing about vcpkg, though, is that all packages are described in the vcpkg source tree. There are no “repositories”. Customizing or adding custom packages requires using the somewhat annoying to use overlay system. I’d prefer some sort of hybrid between the two, with packages distributed as source code but pulled from a repository. I believe this is how Rust’s Cargo works.
  - dgellow 6y ago
    Just to add a small detail: vcpkg also has Visual Studio integration, not only CMake. And regarding repositories, since February 2021 vcpkg has an experimental support for them. You can read the spec here: https://github.com/microsoft/vcpkg/blob/master/docs/specifications/registries-2.md https://github.com/microsoft/vcpkg/blob/master/docs/specific....
scoutt 6y ago
No matter the implemented package manager solution, it has deal with different packages types: from a single class library (a single hpp file) up to monster libraries like ffmpeg. In the case of ffmpeg, what the package manager should do? Download the sources and all its dependencies and build from scratch? This is very difficult and time consuming. Because right now the alternative is going to the ffmpeg website, download and include the dll (and lib) or .so and a couple of .h files to your project. And that's pretty simple to me.
- DubiousPusher 6y ago
  It's not that the package manager fixes the problem, it's that having 1 or maybe 2 or 3 canonical or popular package managers gets the implementer to fix the problem. The implementer, who has extensive knowledge of their own build system runs that aspect and creates a package that conforms to a universally expected output. It's an incredible difference going from C++, where you end up in the details of all kinds of repos and build systems, to something like C# with Nuget packages where it's a simple command or single click to start using someone else's code.
  - scoutt 6y ago
    Consider that C/C++, being highly portable, has support for many platforms and architectures, including the possibility of cross-compiling. I guess if a package manages works on all those architectures and platforms, then the implementer would have to support all of them, and it's not always the main objective. Let alone if there are several package managers.
    - DubiousPusher 6y ago
      > guess if a package manages works on all those architectures and platforms, then the implementer would have to support all of them, Other "highly portable" languages handle this by simply having the developer include a manifest of the platforms their library works for. The package manager only shows compatible packages for the targeted platform.
- 6y ago
bjornjajayaja 6y ago
I think the barrier to entry in the problem domain for C++ is much higher than something like nodejs. Installing dependencies is the least of one’s worries there. Also, how many dependencies are we talking about? Node apps have a million dependencies for, I think, stupid simple stuff that should just be reinvented in a given codebase. In a C++ app too many dependencies invites incompatible stylistic choices which I think will turn to a Frankenstein codebase. In Go this isn’t a problem because of “go fmt” plus a simple language at its core.
gspr 6y ago
Seems weird to have a language fill in the deficiencies of OSes wrt package management.

dgellow 6y ago

Have you tried vcpkg? https://github.com/Microsoft/vcpkg https://github.com/Microsoft/vcpkg It's a tool to manage C++ dependencies (using CMake), created and maintained by Microsoft. A lot of open source projects are supported (you can see part of the list here: https://github.com/microsoft/vcpkg/tree/master/ports https://github.com/microsoft/vcpkg/tree/master/ports).

Const-me 6y ago
I did, about a year ago. The usability was questionable. Their main workflow appears to be, all developers use that thing, everyone building packages from source code and using their own binaries. For large dependencies that’s a large waste of time if more than 1 person is working on the software. It’s possible to export built libraries as nuget packages, but these are tricky to consume. Another thing, these ports (where they applying patches to third party open-source code to squeeze them into vcpkg) are fragile. I remember cases when packages didn’t build, either at all, or subject to conditions (half of what I tried was broken when I only wanted release configurations).
- dgellow 6y ago
  I believe that's a recent development but vcpkg has decent binary caching now: https://github.com/microsoft/vcpkg/blob/master/docs/users/binarycaching.md https://github.com/microsoft/vcpkg/blob/master/docs/users/bi.... Edit: they also have an experimental support for registries since February of this year: https://github.com/microsoft/vcpkg/blob/master/docs/specifications/registries-2.md https://github.com/microsoft/vcpkg/blob/master/docs/specific...
- snarfy 6y ago
  Without a standard ABI, having c++ binary packages is a huge pain, requiring multiple artifacts for every permutation of compiler, os, and platform. It's less painful today than in the past, simply due to fewer compilers, OSes, and platforms, but it is still a problem.
  - Const-me 6y ago
    All developers on that team used 1 compiler (VC++ 2017 at that time), one OS (Windows 10), one target platform (AMD64). Compiler/linker settings are shared across developers. I wanted vcpkg to export just the required artifacts (headers, DLLs, static libraries, and debug symbols), so only 1 person on the team (me) is wasting time building these third-party libraries. The team is remote, upload/download size needs to be reasonable.
    - meragrin_ 6y ago
      I have been using it since at least 2018 to create NuGet packages of dependencies. You can also do zip and others.
  - bluGill 6y ago
    A common ABI doesn't save anything as we still need to build for ARM, and x86 (MIPS, RISCV are also out there and may be important to you). Those processors all have different generations, it might be worth having a build for each variant of your CPUs. Once you take care of that different ABIs are just a trivial extension. RPM and .deb have been able to handle this for years.
- jcelerier 6y ago
  > For large dependencies that’s a large waste of time if more than 1 person is working on the software. but all other hype languages do this and you don't hear people complaining
  - dgellow 6y ago
    Maybe a difference is that C++ can be very, very slow to build. And C++20 will likely results in even longer build time now that you have concepts and can have exceptions and allocations in a constexpr context.
  - throwaway894345 6y ago
    What's a "hype language"?
    - jcelerier 6y ago
      Rust, Go, Julia, Swift ?
      - throwaway894345 6y ago
        What makes them hype languages? Oh, so like new languages?
        jcelerier 6y ago
        > What makes them hype languages? being high in the chart here: https://insights.stackoverflow.com/survey/2020#technology-most-loved-dreaded-and-wanted-languages-loved https://insights.stackoverflow.com/survey/2020#technology-mo...
        throwaway894345 6y ago
        Ah, so hype == love.
        6y ago

vlovich123 6y ago

Widely adopted source code manager requires a widely adopted build system. CMake is certainly a contender but the ecosystem is too fragmented even then & you have to do a lot to try to link disparate build systems together. Also C++ is a transitive dependency hell nightmare & any attempt to solve that (like Rust has) would break every ABI out there. Given how bumpy such breakages have been in the past, I don't think there's any compiler maintainer eager for it (even MSVC has decided to largely ossify their STL runtime ABI). Conan is certainly a laudable attempt at something like this. Without access to their metrics though, it's hard to tell if they're continuing to gain meaningful traction or if their growth curve has plateaued. It's certainly not in use in any project at medium to bigger size companies I've worked at. By comparison, Cocoapods was pretty successful in the iOS ecosystem precisely because Xcode was the de facto build/project system.

mikepurvis 6y ago
I'm a longtime CMake user, but I think even within the CMake world, the solution is quite a bit more complicated than just "everything needs to be CMake", with a lot of hassles that arise when multiple generations of the tooling is involved, when you're trying to pass down transitive dependencies, when package X has a bunch of custom find modules with magic to try to locate system versions of dependencies but silently fall back to vendored ones. The higher up the stack you get, the worse and worse these problems get, with high-level packages like Tensorflow being completely intractable: https://github.com/tensorflow/tensorflow/tree/master/tensorflow/lite/tools/cmake/modules https://github.com/tensorflow/tensorflow/tree/master/tensorf...
- vlovich123 6y ago
  Yup. 100% agree. I totally overlooked the shitshow you'll have managing the different versions of CMake a build might require. Somehow Bazel manages to escape that mess. I think that might be a better foundation, but getting everyone to port to that... it's a tall ask & there's many vocal people who are against improving the build system they work with (hell, I've met many engineers who grumble and strongly prefer Makefiles).

bregma 6y ago

We'd also need the one operating system on the one architecture. Perhaps the central planning committee can make that a goal for their next five year plan?

mikepurvis 6y ago
Python, Ruby, Node, Go, and Rust all work on multiple OSes and arches.
- bregma 6y ago
  Python and Ruby only work on the Python and Ruby interpreters, respectively, and those require an OS-specific way to install them. They work on multiple OSes and architectures as well as JavaScript or HTML. Go and Rust work only on a very very limited set of OSes and architectures. That's fine if you're targeting one of those, but it turns out the vast majority of computers in the world are not vanilla rice-pudding desktop systems or vanilla rice-pudding desktop systems adapted for the server room. The argument that some other tool solves a limited set of problems with your tool in a limited and limiting way is a poor one if you're trying to promote a universal solution.
  - oblio 6y ago
    Java runs on many platforms (and billions of devices as Sun used to love to point out), yet packaging and dependency management are pretty much solved problems. Where there's a will, there's a way. In the C/C++ community there's no will. It's time they admit that to themselves and everyone else.
    - bregma 6y ago
      Java runs only on the Java interpreter. C and C++ run on the bare metal of the CPU. Is Java modeled around a central repository of all dependencies so users can download random binaries off the internet?
      - 6y ago

pjmlp 6y ago

Just like the sibling comment, I would vouch for vcpkg, although for my use cases NuGET will also do.

oregontechninja 6y ago

I've been using conan pretty easily. My biggest issue is that the recommended install method is via Python's pip

jasode 6y ago

>I hope one day we can get a widely adopted C and C++ package manager. [...] , but if it were as easy as “npm install skia”, etc. everywhere, It's not just the package manager (the command line tool) ... it's the canonical website source that the tool pulls from. C++ probably won't have a package manager with the same breadth of newer language ecosystems like npm/Nodejs and crates.io/Rust because for 20+ years C++ was developed by fragmented independent communities before a canonical repo website funded by a corporation or non-profit was created. There is no C++ institution or entity with industry-wide influence that's analogous to Joyent (Nodejs & npm) or Mozilla (Crates.io & cargo) I wrote 2 previous linked comments about this different timeline: https://news.ycombinator.com/item?id=24846012 https://news.ycombinator.com/item?id=24846012 Tldr, 2 opposite timelines happened: - C++ for 20+ years of isolated and fragmented development groups creates legacy codebases --> then decades later try to create package manager (vcpkg? Conan? cppget?) that tries to attracts those disparate groups --> thus "herding cats" is an uphill challenge - npm and crates.io exist at the beginning of language adoption allowing the ecosystem to grow around those package tools and view them as canonical

coder543 6y ago
Go has a perfectly good package manager that works with sources hosted on GitHub and other sites -- there isn't any centralized place for people to publish sources, unlike the other package managers you mentioned. Go's package manager also came years after the language became widely used, and it is now very widely adopted according to the most recent survey[0]. I think C++ could have a good, unified package management story. It would just require the major stakeholders to all care enough to make it happen, which seems to be the missing piece here. [0]: https://blog.golang.org/survey2020-results#TOC_8 https://blog.golang.org/survey2020-results#TOC_8.
- jasode 6y ago
  >Go's package manager also came years after the language became widely used, and it is now very widely adopted according to the most recent survey[0]. Are you talking about "pkg.go.dev" and the "go get" command? Isn't there some path dependence in the history of events that's not comparable to C++? Consider: - Go language: created by Google Inc - "go get" syntax for package download designed and created by Google Inc - "pkg.go.dev" funded by Google Inc and highlighted on "golang.org" website that's also run by Google Inc. There is no business entity or institution in the C++ world that's analogous to Google's influence for Go + golang.org + "go get" + pkg.go.dev. >It would just require the major stakeholders to all _care_ enough to make it happen, But it's easier to care if there was an influential C++ behemoth that captured everyone's mindshare to move the entire ecosystem forward. C++ has no such "industry leader" that dictates (or heavily influences) technical direction from the top down.

bluGill 6y ago

Rust's package management is actually a downside to my adoption. I have a lot of C++, a home-grown package manager, and a large cmake based build system. Rust wants to replace all this, but that means shelling out to Rust's build system, which is a bit of a messy situation and means I need to learn a new build system with the language. (not hard, but another thing to learn). Our home grown package manager means we have our own local copy of everything - I have a hard requriement to be able to rebuild software for the next 15 years (there is a closet someplace with a windows XP service pack 1 PC so we can build some old software - God only knows if it will boot anymore). In the embedded space we need to support our old code for years, and you can't always upgrade to the latest.

coder543 6y ago
"cargo vendor" enables you to embed your entire dependency tree into your repo instantly, and compilation will work from that. Over half of your comment seems to have been predicated on the assumption that this either wasn't possible or wasn't easy... so I think your perceptions of Rust's package management system are more of an impediment to you than the actual package management system.
- saurik 6y ago
  Oooo... does Rust have a good way to do this with submodules instead of copies?
  - coder543 6y ago
    It sounds like you're implying git submodules are actually a good thing... I think you're the first person who has implied such a thing to me before. Everyone I actually know agrees that submodules are basically never the right solution or a pleasant solution. But, to your question, no. Where would the submodules even point? The dependency source code artifacts are stored "immutably" (except for takedown notices or extreme abuse cases) on https://crates.io https://crates.io. They aren't git repos, and there's nowhere for git to point.

fsloth 6y ago

"I think many people would use the language more" C++ is considered the industry leading language in many fields. I'm not sure how many more you would want (given that those fields that don't use C++ ARE probably better served with some other language). I agree the build is painfull, but large orgs have for this reason specifically implemented build systems using nugets, conan/cmake or whatnot. In personal projects I just download the prebuilt binaries of component libraries and drag and drop them to visual studio, minimizing hassle. If you discard finesse and scalability as requirements you can actually jury rig a C++ project in a jiffy. You just need to let go of the idea that it must be "industry standard setup".

throwaway894345 6y ago
C++ used to be the industry leading language in many more fields, but it lost ground to other languages. Not a bad thing--"know thyself" and all that. But Rust seems like a credible threat to C++'s remaining niches (bury your head in the sand if you want), and C++ will need to evolve if it is to not lose further market-/mindshare. And it is evolving, as this article points out, but a huge glaring pain point in C++ development remains the build and package management tooling. The aforementioned build systems that large organizations operate aren't nearly as nice as, say, Cargo and I think a lot of greenfield projects who have to choose between cobbling together their own build tool to work with C++ and using Rust + Cargo off the shelf will choose the latter (other factors notwithstanding).
- pjmlp 6y ago
  I will get worried when NVidia releases CUDA-Rust, and changes their GPGPUs from C++ memory model to Rust, Microsoft decides to rewrite WinUI in Rust, Apple moves Metal from C++ into Rust, or Unreal/Unity get rewritten in Rust.
  - throwaway894345 6y ago
    Like I said: > bury your head in the sand if you want Great chat, as always. :)

throwaway894345 6y ago

> Rust has package management, but not the ecosystem yet. On the other hand, C/C++ has the ecosystem, but no standard way to easily draw from it. I take your point, and I share your desire for a canonical, Cargo-like package manager and build tool for C++ (it's one of the reasons I pivoted out of C++ development); however, I don't think C/C++ "has the ecosystem" these days. It certainly has an ecosystem--C/C++ dominates its own niches, but there's a big world outside those niches and there aren't good packages for much of it. Meanwhile, Rust is growing like a weed both inside and outside of the C/C++ niches, and the package manager largely enables that rapid growth. Also, Rust has a good interop story for C/C++, allowing it to leverage the existing C/C++ ecosystem. Anyway, I hope this doesn't read as contrarianism--I just thought it was an interesting distinction.

pjmlp 6y ago
Most of the places where C++ doesn't have good libraries I wouldn't want to use Rust anyway, that is the domain of managed languages, GUIs, distributed computing, Web development. And for the stuff I use C++ for, COM/UWP, Android NDK, GPGPU shaders, Unreal/Unity, Rust tooling is yet WIP or requires to leave the confort of the existing C++ frameworks and IDE integrations.
- throwaway894345 6y ago
  I would use Rust for distributed computing and GUIs, and I wouldn't be surprised if it begins to break into the graphics/gamedev world in the next 5 years. Agreed that Rust is still immature in those areas today, but it seems to be on a pretty aggressive trajectory and it's only a matter of time before Rust begins chipping away in those domains. I did some real-time embedded development (including distributed embedded) in a past life in C and C++, and I really expect Rust to break through in that domain in a big way even though it's incredibly conservative (C++ is still the new kid on the block). It will take some time and it's never going to "kill" C or C++ in that domain (especially considering all the hardware that exists that LLVM doesn't yet target), but I think Rust will carve out a swathe of the embedded space for itself.
  - 6y ago

mackal 6y ago

I actually extremely dislike language specific package managers. I'm on Linux, the packages should be in my package manager. I don't want to maintain multiple package managers. nmp is actually the worst here.

Koshkin 6y ago
Great point. I think BSDs got this right with their ports. (Incidentally, NetBSD's pkgsrc supports Linux.)
Ar-Curunir 6y ago
The Linux model of package management doesn't work for newer languages. In particular it is heavily reliant on dynamic linking, which tends not to work when you have (a) an unstable ABI (b) generics (c) a culture of static linking.
- beojan 6y ago
  It works fine, you just ship the static libraries. With static linking your binaries won't have dependencies anyway. That's not to say the static linking craze is a good thing. We'd be far better off finding a way to dynamically link templates, so you get the security benefits of automatically updated dependencies that dynamic linking gives you.
gowld 6y ago
Code library managers don't belong inside OS package managers (because you want hermetic builds), unless maybe you have some Nix-live multi-manager that can provide many environments.
quacker 6y ago
> I actually extremely dislike language specific package managers. I'm on Linux, the packages should be in my package manager. I don't want to maintain multiple package managers. nmp is actually the worst here. As a user of software that doesn't care how it's built, sure. But system package managers are not a solution for general development with C++, or any other language. If I want to use C or C++ to create software, how do I use libraries that aren't available in a system package manager? What if I need a version of a library that's not available in my system package manager? There are answers here but they aren't good answers (build from source, using whichever of N build tools the project happens to use, or hope there are prebuilt libs hosted somewhere) Relying on system package managers to contain dependent libraries makes cross-platform development a complete PITA (more that it already is). Now you need the specific versions of all your libraries in package managers on all platforms, which is a complete non-solution for real development.

flatline 6y ago

Conan is probably the flagship C++ package manager and supports multiple build systems including cmake. Nuget/vcpkg is also usable but does not come with build system integration.

invokestatic 6y ago
Vcpkg has great CMake integration. Further, the model of Conan of distributing a bunch of binaries honestly seems like the wrong approach for C++ where you have to juggle all different sorts of compilers, triples, and ABIs. We use a completely custom toolchain which pretty much rules out Conan. The one annoying thing about vcpkg, though, is that all packages are described in the vcpkg source tree. There are no “repositories”. Customizing or adding custom packages requires using the somewhat annoying to use overlay system. I’d prefer some sort of hybrid between the two, with packages distributed as source code but pulled from a repository. I believe this is how Rust’s Cargo works.
- dgellow 6y ago
  Just to add a small detail: vcpkg also has Visual Studio integration, not only CMake. And regarding repositories, since February 2021 vcpkg has an experimental support for them. You can read the spec here: https://github.com/microsoft/vcpkg/blob/master/docs/specifications/registries-2.md https://github.com/microsoft/vcpkg/blob/master/docs/specific....

scoutt 6y ago

No matter the implemented package manager solution, it has deal with different packages types: from a single class library (a single hpp file) up to monster libraries like ffmpeg. In the case of ffmpeg, what the package manager should do? Download the sources and all its dependencies and build from scratch? This is very difficult and time consuming. Because right now the alternative is going to the ffmpeg website, download and include the dll (and lib) or .so and a couple of .h files to your project. And that's pretty simple to me.

DubiousPusher 6y ago
It's not that the package manager fixes the problem, it's that having 1 or maybe 2 or 3 canonical or popular package managers gets the implementer to fix the problem. The implementer, who has extensive knowledge of their own build system runs that aspect and creates a package that conforms to a universally expected output. It's an incredible difference going from C++, where you end up in the details of all kinds of repos and build systems, to something like C# with Nuget packages where it's a simple command or single click to start using someone else's code.
- scoutt 6y ago
  Consider that C/C++, being highly portable, has support for many platforms and architectures, including the possibility of cross-compiling. I guess if a package manages works on all those architectures and platforms, then the implementer would have to support all of them, and it's not always the main objective. Let alone if there are several package managers.
  - DubiousPusher 6y ago
    > guess if a package manages works on all those architectures and platforms, then the implementer would have to support all of them, Other "highly portable" languages handle this by simply having the developer include a manifest of the platforms their library works for. The package manager only shows compatible packages for the targeted platform.
6y ago

bjornjajayaja 6y ago

I think the barrier to entry in the problem domain for C++ is much higher than something like nodejs. Installing dependencies is the least of one’s worries there. Also, how many dependencies are we talking about? Node apps have a million dependencies for, I think, stupid simple stuff that should just be reinvented in a given codebase. In a C++ app too many dependencies invites incompatible stylistic choices which I think will turn to a Frankenstein codebase. In Go this isn’t a problem because of “go fmt” plus a simple language at its core.

gspr 6y ago

Seems weird to have a language fill in the deficiencies of OSes wrt package management.