4 ms·

Historically the dependency management tool for C++ is the system's package manager, and/or a shell configure/provision script. I don't see any value add to a

• aprdm 6y ago
  What about supporting multiple versions of libraries at a computer? They all support it: npm, rvm, virtualenv, cargo, golang, python, maven and etc. A very common use case is to use some newer version of something than what shipped with the OS but at the same time you don't want to potentially cause instability in the OS... Or you know, developing multiple projects w/ different versions from a single OS. Also in case I really want to do it, I have to go to some obscure website download some payload and read some build instructions to see how to best integrate to my messy CMake/Make system... All of it could literally be replaced by something akin to cppvenv create myproject cppvenv --depend-on grpc-1.40 zeromq json cppvenv build
  • otabdeveloper4 6y ago
    Nix does what you want.
    • arximboldi 6y ago
      Yes, I love Nix. The only caveat is that it does not work on Windows...
  • qppo 6y ago
    You would have to go to some obscure website to download some payload and read build instructions to see how to beat integrate it with your new cppenv program instead. That's the problem to solve, C++ is old and most of it written before those solutions existed, and most of it doesn't use the same set of tools. Like I said, I don't think this isn't a problem or that a solution wouldn't be nice. It's just not functionally different from the myriad of existing solutions.
  • dkersten 6y ago
    You edit your generated makefile or tweak the autoconf (or whatever you used) config to point at a specific version of the library, I guess.
• oblio 6y ago
  > Not as in it isn't a useful thing to have, just that it can't solve the big problem which is that most C++ projects would never support it. For a living language the solution is never: "throw your hands up in the air and give up".
• exDM69 6y ago
  > dependency management tool for C++ is the system's package manager The system package manager has a different purpose than a "development" package manager. The system packages are supposed to give you a consistent set of libraries needed to support the application shipped by the distro. If a package you depend on for daily work, say Firefox, requires libfoo-1.0 and your project needs libfoo-2.1, you're screwed. Similarly if you're supporting an old release myapp-1.0 for some customers and it needs libfoo-1.0, but at the same time you're working on myapp-2.0 which needs libfoo-2.1, you're out of luck. The system package manager just doesn't cut it for development work.
  • rightbyte 6y ago
    You can resolve libs by full name beside the system default version.
• chme 6y ago
  > Historically the dependency management tool for C++ is the system's package manager, and/or a shell configure/provision script. I agree with you here. The system package managers where invented to solve system global dependency problems between libraries/executables as well as provide headers and static libraries for development on the current machine. > I don't see any value add to a "built in" dependency management tool to C++. Not as in it isn't a useful thing to have, just that it can't solve the big problem which is that most C++ projects would never support it. Even if you don't see a need, you have to acknowledge that many other people see the need to have some sort local dependency management, be it compile time like cargo or the different cross-build environments (openembedded, buildroot, co.) or runtime like chroots, containers, virtual machines. It can be argued that the local dependency management solutions are in their infancy.