4 ms·

I really don't understand the idea of a C/C++-specific package manager. C is the baseline API for most systems. Your system package manager is already installin

I really don't understand the idea of a C/C++-specific package manager. C is the baseline API for most systems. Your system package manager is already installing C/C++ libraries and headers. Most platforms even have standard paths for storing C/C++ headers and libraries. Also as a C/C++ guy I could care less if the libraries are written in Brainfuck for what is worth, as long as their API stays usable from C, which is pretty much guaranteed. So the idea of a "C/C++ package manager" seems strange, and even trying to create a barrier where there was none.

doliveira 6y ago
Isn't Docker a thing mainly due to the hassle that it is to manage libraries and headers in C/C++?
- yokaze 6y ago
  That is not C/C++ specific, from what I saw, most "dynamic" languages picked it up rather more enthusiastically. Resolving the conflict of different library dependencies that arises in almost all languages. And with docker I can solve it in a uniform way. If you install something in the system, it will mess it up for others. Some languages do have "native" ways to avoid that, e.g. python has virtualenv, ruby has bundler, java classpaths?... but I still can mess up the system. And it isn't like there are different ways how it is then solved. But with docker, I package and isolate the whole OS. So, as a consumer, I do not have to know how to do that for each language, and as a producer, I can do (almost) whatever I want within the container without fearing to mess up other containers or the hosting OS. Yes, this whole approach has its own downsides. But those things are a plus, I would say.
  - doliveira 6y ago
    Honestly that all seems to mostly derive from C/C++ issues, doesn't it? Managing Python and Ruby is pretty easy until you hit a library with OS dependencies. But I'm there with you, I love Docker. But it is a solution to problems we should not be having after 30-ish years.
    - yokaze 6y ago
      > Managing Python and Ruby is pretty easy until you hit a library with OS dependencies. And that's why there is practically only one solution to solve it in either language (/sarcasm off). Docker in my mind wasn't a sensible choice for compiled languages prior multi-stage builds, or better buildkit. > Honestly that all seems to mostly derive from C/C++ issues, doesn't it? It derives from having binary libraries, and a plethora of ABIs. And contrary to Go advocats and docker fans, I do believe they have their place. There is no perfect technical solution, there is always a trade-off. With compiled languages you deliver binaries. A development / delivery split is expected. The intermediate data (object files + debug data) often need a lot of storage, and are not supposed to be shipped directly. With a binary interface (ABI), you simply can ship your shared object or executable individually. With statically linked/compiled binaries, you have to ship every binary using the fixed library. Or in case of docker, it will likely affect a lower layer which will invalidate all the upper layers of each docker image using said library. So a couple of bytes delta in a couple of KB library can mean a couple of KB binary package, or a couple of multi-mb binaries or layers containing all the upper parts. Your OS is most likely working with shared objects/DLLs and their ABIs, and there is a reason for that. Your use-case might not demand that, and that is okay, but it doesn't invalidate that there is a sensible reason for doing it the way it is done.
    - barumi 6y ago
      > Honestly that all seems to mostly derive from C/C++ issues, doesn't it? No, it's not. It's exclusively derived from the fact that there is no package manager. Python has a few package managers. Node.js also has package managers, and Rust has too. In C or C++ the only package manager there is is a linux distro's own generic package manager, which isn't exactly designed to handle independent projects. There is no coincidence in the fact that node.js's npm and conan are services offered by private for-profit companies which have a free tier and paid tier targeting enterprise customers. It's no coincidence because packaging and distribution is a generic software engineering need that is not tied to a specific programming language, and is value-added that, done right, is worth paying for.
- barumi 6y ago
  The value of Docker is not packaging per se. It's like a linux installer: yeah it's great that they come bundled ina neat ISO image that you can burn/copy/run in place, but that's not it's value proposition. It's value proposition is that you have a self-contained software packages that can be executed at will free from side-effects.
Fronzie 6y ago
There are two uses cases for package managers. One is as an end-user to install software, another as a developer to have a set of specific libraries to use. For the latter, the version used varies per project. The former is typically system wide. For my hobby projects, I indeed use cmake to generate .deb packages which I then use in other projects. For professional development I've never seen this work successfully.
yokaze 6y ago
Sure there is a barrier and it is the same as for other programming languages. If you rely on your package manager, you are basically stuck with whatever was in the previous LTS of ubuntu when it was shipped. If you want the newest library, then you are either dependent on some external proper packager, or you have to get into packaging yourself. I don't consider picking a random external source something I would do in a professional context. But if we open up the choice of library versions from "non-standard" versions, the problem becomes a transient one. Team A in location B needs at least version X, but not version Y, team C in location D won't do with version Z. To give that kind of flexibility, people went for build from source instead (Go, Java,...) And in every shop I have worked until now, "your package manager" meant usually having to support at least one linux distribution in two versions, Windows and Mac, which do not have a native package manager.
- barumi 6y ago
  > If you rely on your package manager, you are basically stuck with whatever was in the previous LTS of ubuntu when it was shipped. This is not exactly true. You are free to put together your company's PPA, and just package your stuff as you see fit. You know, use the system's package manager to serve your and your user's interests. > If you want the newest library, then you are either dependent on some external proper packager, or you have to get into packaging yourself. I don't consider picking a random external source something I would do in a professional context. If you're in a "professional context" then you're already in the business of packaging and distributing software packages.
  - yokaze 6y ago
    > You are free to put together your company's PPA, and just package your stuff as you see fit. I think, I've addressed that point and it's downsides. > If you're in a "professional context" then you're already in the business of packaging and distributing software packages. Nowadays, you often aren't. A lot of companies switch to the software-as-a-service model and it's distributing and packaging and distribution are two of the major problems solved by that.
detaro 6y ago
Your system package manager typically also sucks for keeping multiple versions/variants of libraries around, and library developers aren't particularly interested in providing packages for many different systems. Not all platforms even have a system package manager you can easily add your own packages to.
- tarruda 6y ago
  Linux package managers have no problem with multiple versions of a library: https://unix.stackexchange.com/a/209712 https://unix.stackexchange.com/a/209712
  - mook 6y ago
    Linux package managers (that I'm aware of) tend to dislike keeping multiple versions of development headers around, though; they have no issues keeping multiple versions of the libraries themselves. That seems relevant in a discussion about a development library. I understand that nix might be a notable exception here.
    - barumi 6y ago
      > Linux package managers (that I'm aware of) tend to dislike keeping multiple versions of development headers around, though; They really don't. At most, those doing the packaging lack the insight to allow users to install separate versions of the same package. You only need to allow your package to not reuse another release's path, and allow users to use a generic major/minor version of a package, and that's it.
- chriswarbo 6y ago
  I think Nix does a pretty good job at this. I've used it on Ubuntu, macOS and NixOS (with the latter two sharing the same system config, with OS-specific pieces tucked into if/else expressions). I think of Nix more as a build system than a package manager (and in fact I've come to think of "package managers" as a sub-set of build systems, mostly used to work around deficiencies in Make which make it unsuitable for building whole operating systems via composition of their Makefiles). One thing that Nix emphasises is that users should not be installing dependencies, like libraries; let alone in a globally visible, ambiguous location like '/usr/lib' (or /usr/bin, etc. if it's a tool that we're depending on). Dependencies are only needed 'ambiently' in a package's build environment; build products can embed references those by absolute path if they like, but they shouldn't be 'propagated' into the final system.
flohofwoe 6y ago
"Most platforms" unfortunately excludes Windows, which is too popular to ignore.
- barumi 6y ago
  Among the available platforms, Windows is by far the less picky about libraries and project setup. You pretty much only need to dump all interface headers in any part of your file system, dump your libraries somewhere else, and then point your project files to it. Afterwards you just need to ensure you nearly bundle your DLLs, and you're all set.
  - flohofwoe 6y ago
    Sure, but you get that sort of "freedom" on any other platform too. Unlike UNIX-y operating systems, Windows has no notion of a standard location for headers and libraries which package managers and compiler toolchains all agree on.
mhh__ 6y ago
This kind of ignores the realities of some big projects, i.e. managing dependencies automatically in Qt (and in a licence conforming way) is an absolute pain. I don't want to try every single combination of static/shared etc. to find what works, that and deploying the executable, again, should be automated. QMake is old but functional, CMake is more up to date but a total pain if you use it irregularly. I've never used Conan so I can't comment on it. It's slightly ridiculous that this is still a pain point when Rust has cargo and D has dub - both of them not perfect, but totally functional and basically painless for the most part.
- barumi 6y ago
  > QMake is old but functional, CMake is more up to date but a total pain if you use it irregularly. In my experience it's the exact opposite. Cmake can be a real treat to use, provided you follow the so-called modern cmake approach, and qmake is just an unmaintainable mess of a system. > I've never used Conan so I can't comment on it. Conan is pretty much orthogonal to any build system. Conan's responsibility is pretty much limited to managing the project's third-party libraries: it handles downloading their interfaces and libraries, pass their settings, and just integrate them into your project with as little code as possible. There is indeed some modules for CMake that offer some limited functionality that allows third-party packages to be integrated, such as the ExternalProject module. However, those were an afterthought that only add complexity to a project.
hobby-coder-guy 6y ago
Couldn't care less. Why do people keep doing this?

doliveira 6y ago

Isn't Docker a thing mainly due to the hassle that it is to manage libraries and headers in C/C++?

yokaze 6y ago
That is not C/C++ specific, from what I saw, most "dynamic" languages picked it up rather more enthusiastically. Resolving the conflict of different library dependencies that arises in almost all languages. And with docker I can solve it in a uniform way. If you install something in the system, it will mess it up for others. Some languages do have "native" ways to avoid that, e.g. python has virtualenv, ruby has bundler, java classpaths?... but I still can mess up the system. And it isn't like there are different ways how it is then solved. But with docker, I package and isolate the whole OS. So, as a consumer, I do not have to know how to do that for each language, and as a producer, I can do (almost) whatever I want within the container without fearing to mess up other containers or the hosting OS. Yes, this whole approach has its own downsides. But those things are a plus, I would say.
- doliveira 6y ago
  Honestly that all seems to mostly derive from C/C++ issues, doesn't it? Managing Python and Ruby is pretty easy until you hit a library with OS dependencies. But I'm there with you, I love Docker. But it is a solution to problems we should not be having after 30-ish years.
  - yokaze 6y ago
    > Managing Python and Ruby is pretty easy until you hit a library with OS dependencies. And that's why there is practically only one solution to solve it in either language (/sarcasm off). Docker in my mind wasn't a sensible choice for compiled languages prior multi-stage builds, or better buildkit. > Honestly that all seems to mostly derive from C/C++ issues, doesn't it? It derives from having binary libraries, and a plethora of ABIs. And contrary to Go advocats and docker fans, I do believe they have their place. There is no perfect technical solution, there is always a trade-off. With compiled languages you deliver binaries. A development / delivery split is expected. The intermediate data (object files + debug data) often need a lot of storage, and are not supposed to be shipped directly. With a binary interface (ABI), you simply can ship your shared object or executable individually. With statically linked/compiled binaries, you have to ship every binary using the fixed library. Or in case of docker, it will likely affect a lower layer which will invalidate all the upper layers of each docker image using said library. So a couple of bytes delta in a couple of KB library can mean a couple of KB binary package, or a couple of multi-mb binaries or layers containing all the upper parts. Your OS is most likely working with shared objects/DLLs and their ABIs, and there is a reason for that. Your use-case might not demand that, and that is okay, but it doesn't invalidate that there is a sensible reason for doing it the way it is done.
  - barumi 6y ago
    > Honestly that all seems to mostly derive from C/C++ issues, doesn't it? No, it's not. It's exclusively derived from the fact that there is no package manager. Python has a few package managers. Node.js also has package managers, and Rust has too. In C or C++ the only package manager there is is a linux distro's own generic package manager, which isn't exactly designed to handle independent projects. There is no coincidence in the fact that node.js's npm and conan are services offered by private for-profit companies which have a free tier and paid tier targeting enterprise customers. It's no coincidence because packaging and distribution is a generic software engineering need that is not tied to a specific programming language, and is value-added that, done right, is worth paying for.
barumi 6y ago
The value of Docker is not packaging per se. It's like a linux installer: yeah it's great that they come bundled ina neat ISO image that you can burn/copy/run in place, but that's not it's value proposition. It's value proposition is that you have a self-contained software packages that can be executed at will free from side-effects.

Fronzie 6y ago

There are two uses cases for package managers. One is as an end-user to install software, another as a developer to have a set of specific libraries to use. For the latter, the version used varies per project. The former is typically system wide. For my hobby projects, I indeed use cmake to generate .deb packages which I then use in other projects. For professional development I've never seen this work successfully.

yokaze 6y ago

Sure there is a barrier and it is the same as for other programming languages. If you rely on your package manager, you are basically stuck with whatever was in the previous LTS of ubuntu when it was shipped. If you want the newest library, then you are either dependent on some external proper packager, or you have to get into packaging yourself. I don't consider picking a random external source something I would do in a professional context. But if we open up the choice of library versions from "non-standard" versions, the problem becomes a transient one. Team A in location B needs at least version X, but not version Y, team C in location D won't do with version Z. To give that kind of flexibility, people went for build from source instead (Go, Java,...) And in every shop I have worked until now, "your package manager" meant usually having to support at least one linux distribution in two versions, Windows and Mac, which do not have a native package manager.

barumi 6y ago
> If you rely on your package manager, you are basically stuck with whatever was in the previous LTS of ubuntu when it was shipped. This is not exactly true. You are free to put together your company's PPA, and just package your stuff as you see fit. You know, use the system's package manager to serve your and your user's interests. > If you want the newest library, then you are either dependent on some external proper packager, or you have to get into packaging yourself. I don't consider picking a random external source something I would do in a professional context. If you're in a "professional context" then you're already in the business of packaging and distributing software packages.
- yokaze 6y ago
  > You are free to put together your company's PPA, and just package your stuff as you see fit. I think, I've addressed that point and it's downsides. > If you're in a "professional context" then you're already in the business of packaging and distributing software packages. Nowadays, you often aren't. A lot of companies switch to the software-as-a-service model and it's distributing and packaging and distribution are two of the major problems solved by that.

detaro 6y ago

Your system package manager typically also sucks for keeping multiple versions/variants of libraries around, and library developers aren't particularly interested in providing packages for many different systems. Not all platforms even have a system package manager you can easily add your own packages to.

tarruda 6y ago
Linux package managers have no problem with multiple versions of a library: https://unix.stackexchange.com/a/209712 https://unix.stackexchange.com/a/209712
- mook 6y ago
  Linux package managers (that I'm aware of) tend to dislike keeping multiple versions of development headers around, though; they have no issues keeping multiple versions of the libraries themselves. That seems relevant in a discussion about a development library. I understand that nix might be a notable exception here.
  - barumi 6y ago
    > Linux package managers (that I'm aware of) tend to dislike keeping multiple versions of development headers around, though; They really don't. At most, those doing the packaging lack the insight to allow users to install separate versions of the same package. You only need to allow your package to not reuse another release's path, and allow users to use a generic major/minor version of a package, and that's it.
chriswarbo 6y ago
I think Nix does a pretty good job at this. I've used it on Ubuntu, macOS and NixOS (with the latter two sharing the same system config, with OS-specific pieces tucked into if/else expressions). I think of Nix more as a build system than a package manager (and in fact I've come to think of "package managers" as a sub-set of build systems, mostly used to work around deficiencies in Make which make it unsuitable for building whole operating systems via composition of their Makefiles). One thing that Nix emphasises is that users should not be installing dependencies, like libraries; let alone in a globally visible, ambiguous location like '/usr/lib' (or /usr/bin, etc. if it's a tool that we're depending on). Dependencies are only needed 'ambiently' in a package's build environment; build products can embed references those by absolute path if they like, but they shouldn't be 'propagated' into the final system.

flohofwoe 6y ago

"Most platforms" unfortunately excludes Windows, which is too popular to ignore.

barumi 6y ago
Among the available platforms, Windows is by far the less picky about libraries and project setup. You pretty much only need to dump all interface headers in any part of your file system, dump your libraries somewhere else, and then point your project files to it. Afterwards you just need to ensure you nearly bundle your DLLs, and you're all set.
- flohofwoe 6y ago
  Sure, but you get that sort of "freedom" on any other platform too. Unlike UNIX-y operating systems, Windows has no notion of a standard location for headers and libraries which package managers and compiler toolchains all agree on.

mhh__ 6y ago

This kind of ignores the realities of some big projects, i.e. managing dependencies automatically in Qt (and in a licence conforming way) is an absolute pain. I don't want to try every single combination of static/shared etc. to find what works, that and deploying the executable, again, should be automated. QMake is old but functional, CMake is more up to date but a total pain if you use it irregularly. I've never used Conan so I can't comment on it. It's slightly ridiculous that this is still a pain point when Rust has cargo and D has dub - both of them not perfect, but totally functional and basically painless for the most part.

barumi 6y ago
> QMake is old but functional, CMake is more up to date but a total pain if you use it irregularly. In my experience it's the exact opposite. Cmake can be a real treat to use, provided you follow the so-called modern cmake approach, and qmake is just an unmaintainable mess of a system. > I've never used Conan so I can't comment on it. Conan is pretty much orthogonal to any build system. Conan's responsibility is pretty much limited to managing the project's third-party libraries: it handles downloading their interfaces and libraries, pass their settings, and just integrate them into your project with as little code as possible. There is indeed some modules for CMake that offer some limited functionality that allows third-party packages to be integrated, such as the ExternalProject module. However, those were an afterthought that only add complexity to a project.

hobby-coder-guy 6y ago

Couldn't care less. Why do people keep doing this?