4 ms·

> Did C++ not already have a fully featured package manager until now? There are several competing projects, but no clear winner yet. And a lot of people a com

by usrnm 7y ago

> Did C++ not already have a fully featured package manager until now? There are several competing projects, but no clear winner yet. And a lot of people a companies prefer to build their stuff themselves for additional control. > Why not? It's complicated. In a few words, it's practically impossible to build a general tool that could suit everybody's needs.

capableweb 7y ago
> it's practically impossible to build a general tool that could suit everybody's needs. Indeed and that's not what npm or maven aims for either, no tool fits everybody's need, not even npm! Probably there is a deeper issue than "it's hard", or if it's "just hard", why is so much harder for C++ than for the JavaScript folks?
- usrnm 7y ago
  There is no compilation step in the js world, or any other interpreted language for that matter. Even in case of JIT, it happens completely transparently and has no effect on the package you download from npm. Nobody distributes JIT'ed code. C++, on the other hand, doesn't work like that. Source code needs to be compiled to be usable and the exact way it is supposed to be compiled varies enormously between different projects. Not to mention that there are usually lots of compiler options and project-specific macro definitions that you might want to change to get the exact binary you need. Compilation matters, it matters a lot, and it cannot be easily abstracted away without sacrifising performance and flexibility.
  - yunyu 7y ago
    Plenty of npm/pypi modules require building platform-specific native code (see node-gyp, wheel), and a lot of JS packages require transpilation. I don't find this argument particularly compelling.
- shakna 7y ago
  > why is so much harder for C++ than for the JavaScript folks? There are C++ package managers that exist and work - they tend to be your OS' package manager, because of the problems they will have to work around. Because C++ has a lot more flexibility in core components than JavaScript does, which aren't easy to resolve at the package manager level. Things projects may _require_ to build correctly: * Multiple compilers that don't always have compatible extensions that sometimes share the same flags, and can falsely report to be each other when queried. * Multiple simultaneous differing versions of clib to link against. They may requiring differing specific versions of specific implementations. * Specific kernel libraries to link against. You can't easily build and link against a specific OS kernel in isolation. * Projects may expect specific paths, and ignore or break attempts to change these. Not being able to compile a project that has a history of twenty years isn't an option. * Arbitrary execution with intentional side-effects. It's bad, but there is a very long history of projects that you're dealing with here. * CPATH and CXXPATH are globals. Relative path linking is possible, but difficult and a pile of hacks. You can force a node_modules style to exist, and some projects do, but most are a mix of relative and global, and the global can override your local and break things.

by usrnm 7y ago

capableweb 7y ago

> it's practically impossible to build a general tool that could suit everybody's needs. Indeed and that's not what npm or maven aims for either, no tool fits everybody's need, not even npm! Probably there is a deeper issue than "it's hard", or if it's "just hard", why is so much harder for C++ than for the JavaScript folks?

usrnm 7y ago
There is no compilation step in the js world, or any other interpreted language for that matter. Even in case of JIT, it happens completely transparently and has no effect on the package you download from npm. Nobody distributes JIT'ed code. C++, on the other hand, doesn't work like that. Source code needs to be compiled to be usable and the exact way it is supposed to be compiled varies enormously between different projects. Not to mention that there are usually lots of compiler options and project-specific macro definitions that you might want to change to get the exact binary you need. Compilation matters, it matters a lot, and it cannot be easily abstracted away without sacrifising performance and flexibility.
- yunyu 7y ago
  Plenty of npm/pypi modules require building platform-specific native code (see node-gyp, wheel), and a lot of JS packages require transpilation. I don't find this argument particularly compelling.
shakna 7y ago
> why is so much harder for C++ than for the JavaScript folks? There are C++ package managers that exist and work - they tend to be your OS' package manager, because of the problems they will have to work around. Because C++ has a lot more flexibility in core components than JavaScript does, which aren't easy to resolve at the package manager level. Things projects may _require_ to build correctly: * Multiple compilers that don't always have compatible extensions that sometimes share the same flags, and can falsely report to be each other when queried. * Multiple simultaneous differing versions of clib to link against. They may requiring differing specific versions of specific implementations. * Specific kernel libraries to link against. You can't easily build and link against a specific OS kernel in isolation. * Projects may expect specific paths, and ignore or break attempts to change these. Not being able to compile a project that has a history of twenty years isn't an option. * Arbitrary execution with intentional side-effects. It's bad, but there is a very long history of projects that you're dealing with here. * CPATH and CXXPATH are globals. Relative path linking is possible, but difficult and a pile of hacks. You can force a node_modules style to exist, and some projects do, but most are a mix of relative and global, and the global can override your local and break things.