5 ms·

C++ cannot be covered by package management in the same way interpreted languages are. The problem space is vastly more complex. It starts with optional languag

C++ cannot be covered by package management in the same way interpreted languages are. The problem space is vastly more complex. It starts with optional language features that often get get disabled in projects (most often RTTI and exceptions), continues with incompatible ABIs between compilers and even compiler revisions and does not stop with the presence of sometimes countless compiler flags for optional features and dependencies. For all of these reasons it is not possible in the general case (the one that package management needs to target) to simply distribute binaries. Linux distributions are not a working example here because the libraries are built for the use of the other packages in the same repository. Needs of third parties are never considered because finding library configurations that work for the packages in the distro is hard enough. A platform independent package manager for C++ must effectively degrade into a build system that rebuilds all dependencies from source. And it must allow build parameters for each step to be defined by the dependent libraries or programs, so that the result is something that can be linked together successfully.

humanrebar 9y ago
> ...it must allow build parameters for each step to be defined by the dependent libraries or programs... Which will (given enough code being built) lead to incompatible flags amongst dependent packages. Compilers may or may not, at build or link time, give sensible error messages. It would be a very sophisticated package manager that could warn you of these sorts of conflicts at specification or installation time.
cjwoodall 9y ago
To be fair some modern compiled languages are covered by package managers. For example, Rust and Cargo. Admittedly there are constructs built into the language and design that have made the plausible since early on.
- kibwen 9y ago
  Even above any technical aspect, the most important thing about Cargo's success is that it was the official default from day one. There's hardly any question about how packages should build or dependencies should operate. And indeed, Cargo does encourage (though not require) everything to be built from source, which is probably intentional given Mozilla's stance on OSS.
  - cjwoodall 9y ago
    I completely agree.
  - steveklabnik 9y ago
    It has nothing to do with Mozilla, specifically. Binary packages are very tricky. I'm sure Cargo will figure it out and eventually grow support, but this isn't some sort of top-down policy.
    - crzwdjk 9y ago
      It would be kind of difficult to have binary packages unless you have a stable ABI, and Rust doesn't have that yet. If and when it does get a stable ABI, binary packages would at least become a possibility. There are good reasons why Rust didn't want to commit to a stable ABI initially, but perhaps at some point the benefits will outweigh the costs.
      - steveklabnik 9y ago
        You can do it, it just adds another axis to the matrix of things you have to support. It's a significant drawback. Regardless, the point is that all of this is technical and has nothing to do with Mozilla's love of open source.
pjmlp 9y ago
It kind of works with NuGET on Windows.
pcwalton 9y ago
> A platform independent package manager for C++ must effectively degrade into a build system that rebuilds all dependencies from source. And it must allow build parameters for each step to be defined by the dependent libraries or programs, so that the result is something that can be linked together successfully. That's how Cargo works, and it works great.
rdnetto 9y ago
> C++ cannot be covered by package management in the same way interpreted languages are. The problem space is vastly more complex. It starts with optional language features that often get get disabled in projects (most often RTTI and exceptions), continues with incompatible ABIs between compilers and even compiler revisions and does not stop with the presence of sometimes countless compiler flags for optional features and dependencies. Haskell has most of the same problems and Stack handles them easily. Each source file in a project can use different language extensions, all transitive dependencies are compiled from source, and there's even CI to re run tests whenever a package is bumped.

humanrebar 9y ago

> ...it must allow build parameters for each step to be defined by the dependent libraries or programs... Which will (given enough code being built) lead to incompatible flags amongst dependent packages. Compilers may or may not, at build or link time, give sensible error messages. It would be a very sophisticated package manager that could warn you of these sorts of conflicts at specification or installation time.

cjwoodall 9y ago

To be fair some modern compiled languages are covered by package managers. For example, Rust and Cargo. Admittedly there are constructs built into the language and design that have made the plausible since early on.

kibwen 9y ago
Even above any technical aspect, the most important thing about Cargo's success is that it was the official default from day one. There's hardly any question about how packages should build or dependencies should operate. And indeed, Cargo does encourage (though not require) everything to be built from source, which is probably intentional given Mozilla's stance on OSS.
- cjwoodall 9y ago
  I completely agree.
- steveklabnik 9y ago
  It has nothing to do with Mozilla, specifically. Binary packages are very tricky. I'm sure Cargo will figure it out and eventually grow support, but this isn't some sort of top-down policy.
  - crzwdjk 9y ago
    It would be kind of difficult to have binary packages unless you have a stable ABI, and Rust doesn't have that yet. If and when it does get a stable ABI, binary packages would at least become a possibility. There are good reasons why Rust didn't want to commit to a stable ABI initially, but perhaps at some point the benefits will outweigh the costs.
    - steveklabnik 9y ago
      You can do it, it just adds another axis to the matrix of things you have to support. It's a significant drawback. Regardless, the point is that all of this is technical and has nothing to do with Mozilla's love of open source.

pjmlp 9y ago

It kind of works with NuGET on Windows.

pcwalton 9y ago

> A platform independent package manager for C++ must effectively degrade into a build system that rebuilds all dependencies from source. And it must allow build parameters for each step to be defined by the dependent libraries or programs, so that the result is something that can be linked together successfully. That's how Cargo works, and it works great.

rdnetto 9y ago

> C++ cannot be covered by package management in the same way interpreted languages are. The problem space is vastly more complex. It starts with optional language features that often get get disabled in projects (most often RTTI and exceptions), continues with incompatible ABIs between compilers and even compiler revisions and does not stop with the presence of sometimes countless compiler flags for optional features and dependencies. Haskell has most of the same problems and Stack handles them easily. Each source file in a project can use different language extensions, all transitive dependencies are compiled from source, and there's even CI to re run tests whenever a package is bumped.