3 ms·

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 so

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.

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.