3 ms·

The bane of my existence at the moment is the fact that I have this HUGE Boost dependency in my code, even if I'm only using a few packages... It ju

The bane of my existence at the moment is the fact that I have this HUGE Boost dependency in my code, even if I'm only using a few packages... It just startles me that there isn't a single, consolidated package manager... Sincerely, I have never understood this common complaint about C++ (applies to C as well, actually). My OS comes with a huge repo of C++ libraries. For example, there is a separate package for each of the Boost libraries you used as your example. Why do I need a C++-specific package manager? What's the use case? Windows?

ajross 12y ago
Pretty much. In particular, Boost is already packaged and available for clean dependency management on all Linux distros. And on Windows, you're almost always looking at shipping a statically build binary (or one with the DLLs packaged) anyway, so an external package manager would provide little value anyway. Really the existence of language-specific package management might be considered the bug, and not the feature. In all cases I've dealt with, the OS packaging is superior anyway.
- sanderjd 12y ago
  I think it's fascinating how wildly differing peoples' experiences are with this. I find system package managers nice for system administrators and applications, but for development, every one I've used is far less convenient than a purpose-built package ecosystem.
- nawitus 12y ago
  Do you think every Node.js package should be released as an OS level package?
JonathonW 12y ago
Windows. OSX (to some degree; Homebrew and MacPorts mitigate this). Linux if you want library versions newer than those supplied by the distro, if you want something that's not supplied by the distro, or if you want to be able to handle your build in a distro-independent manner (those "separate packages for each of the Boost libraries" you reference are provided by your distribution; Boost themselves only distribute one monolithic package from which you can, with some massaging, pull out individual parts if you really need to). The language-specific package managers used with (for example) Python, Ruby, or Node give developers an OS-agnostic way to pull in dependencies, and, since dependencies are being packaged uniformly, avoids the conflicts between build systems that can make it hard for C++ libraries to coexist (this thing needs CMake, this other guy used Autoconf/Automake, and I've got Boost which built with Bjam, and now I need to make it all work on Windows and they're all providing binaries built with different MSVC versions).
- kartikkumar 12y ago
  This. I've been playing out with Cargo and the Julia package manager and it's so nice to have a consolidated way of dealing with dependencies, included their build-systems. I've now resorted to setting up a template project for myself [1] that uses CMakes ExternalProject_Add to pull in dependencies, configure and build them. ExternalProject_Add is so finicking though. How I'd love a packages.json solution for C++, where I can specific standardized libraries or Github/Bitbucket repositories not provided by the distro/package manager. I'd love to see a Homebrew fork morph into a cross-platform package manager for C++. Would make my life so much easier. [1] https://github.com/kartikkumar/cpp-project https://github.com/kartikkumar/cpp-project EDIT: Added missing reference
- frankzinger 12y ago
  Do you really believe that a C++-specific package manager (PM) repo would somehow be much more up to date than an OS one? Why? Any PM repo will eventually be missing something you need, and then you will have to compile it yourself, and if you've done that a few times you should have an idea of the difficulty involved in providing a set of compiled dependencies for one system, nevermind multiple versions of multiple systems. I don't doubt the usefulness of the Python, Ruby, and Node PMs, but those libraries mostly depend only on the interpreter and other interpreted code. It's just so much simpler. The fact that it's all going through an interpreter (compiled specifically for that system by the system PM in most cases!) solves so many of the problems.
vinkelhake 12y ago
Using the packaged versions that comes with the OS is very convenient if you can live with the versions you get. This means that you might have to update your application code when updating the operating system. This can be fine for open source development, but it has never been acceptable at any closed source shop where I've worked. We wanted the freedom of not updating things in lockstep.
- frankzinger 12y ago
  This is exactly why 'stable' or 'long-term-support' versions of OSes exist. They go out of their way not to break binary compatibility (by not upgrading libraries all the time) so that user code need not be recompiled.
  - vinkelhake 12y ago
    That just means that forced updates are less frequent. The flipside of it is that you are now stuck with, potentially, ancient packages. No matter how you slice it, being tied to the release cycle of the OS has problems. Don't get me wrong, there are definite advantages to sticking with OS-provided packages. I do it for all my personal projects, but it's not a panacea.
    - frankzinger 12y ago
      That is a tradeoff every software repo is faced with (stability vs. new features). Why would a C++-specific PM be able to do it better? Especially considering that it would have to provide compiled binaries for N versions of M OSes/distros (not to mention multiple CPU architectures).

ajross 12y ago

Pretty much. In particular, Boost is already packaged and available for clean dependency management on all Linux distros. And on Windows, you're almost always looking at shipping a statically build binary (or one with the DLLs packaged) anyway, so an external package manager would provide little value anyway. Really the existence of language-specific package management might be considered the bug, and not the feature. In all cases I've dealt with, the OS packaging is superior anyway.

sanderjd 12y ago
I think it's fascinating how wildly differing peoples' experiences are with this. I find system package managers nice for system administrators and applications, but for development, every one I've used is far less convenient than a purpose-built package ecosystem.
nawitus 12y ago
Do you think every Node.js package should be released as an OS level package?

JonathonW 12y ago

Windows. OSX (to some degree; Homebrew and MacPorts mitigate this). Linux if you want library versions newer than those supplied by the distro, if you want something that's not supplied by the distro, or if you want to be able to handle your build in a distro-independent manner (those "separate packages for each of the Boost libraries" you reference are provided by your distribution; Boost themselves only distribute one monolithic package from which you can, with some massaging, pull out individual parts if you really need to). The language-specific package managers used with (for example) Python, Ruby, or Node give developers an OS-agnostic way to pull in dependencies, and, since dependencies are being packaged uniformly, avoids the conflicts between build systems that can make it hard for C++ libraries to coexist (this thing needs CMake, this other guy used Autoconf/Automake, and I've got Boost which built with Bjam, and now I need to make it all work on Windows and they're all providing binaries built with different MSVC versions).

kartikkumar 12y ago
This. I've been playing out with Cargo and the Julia package manager and it's so nice to have a consolidated way of dealing with dependencies, included their build-systems. I've now resorted to setting up a template project for myself [1] that uses CMakes ExternalProject_Add to pull in dependencies, configure and build them. ExternalProject_Add is so finicking though. How I'd love a packages.json solution for C++, where I can specific standardized libraries or Github/Bitbucket repositories not provided by the distro/package manager. I'd love to see a Homebrew fork morph into a cross-platform package manager for C++. Would make my life so much easier. [1] https://github.com/kartikkumar/cpp-project https://github.com/kartikkumar/cpp-project EDIT: Added missing reference
frankzinger 12y ago
Do you really believe that a C++-specific package manager (PM) repo would somehow be much more up to date than an OS one? Why? Any PM repo will eventually be missing something you need, and then you will have to compile it yourself, and if you've done that a few times you should have an idea of the difficulty involved in providing a set of compiled dependencies for one system, nevermind multiple versions of multiple systems. I don't doubt the usefulness of the Python, Ruby, and Node PMs, but those libraries mostly depend only on the interpreter and other interpreted code. It's just so much simpler. The fact that it's all going through an interpreter (compiled specifically for that system by the system PM in most cases!) solves so many of the problems.

vinkelhake 12y ago

Using the packaged versions that comes with the OS is very convenient if you can live with the versions you get. This means that you might have to update your application code when updating the operating system. This can be fine for open source development, but it has never been acceptable at any closed source shop where I've worked. We wanted the freedom of not updating things in lockstep.

frankzinger 12y ago
This is exactly why 'stable' or 'long-term-support' versions of OSes exist. They go out of their way not to break binary compatibility (by not upgrading libraries all the time) so that user code need not be recompiled.
- vinkelhake 12y ago
  That just means that forced updates are less frequent. The flipside of it is that you are now stuck with, potentially, ancient packages. No matter how you slice it, being tied to the release cycle of the OS has problems. Don't get me wrong, there are definite advantages to sticking with OS-provided packages. I do it for all my personal projects, but it's not a panacea.
  - frankzinger 12y ago
    That is a tradeoff every software repo is faced with (stability vs. new features). Why would a C++-specific PM be able to do it better? Especially considering that it would have to provide compiled binaries for N versions of M OSes/distros (not to mention multiple CPU architectures).