7 ms·

>I hope one day we can get a widely adopted C and C++ package manager. [...] , but if it were as easy as “npm install skia”, etc. everywhere, It's not just the

by jasode 6y ago

>I hope one day we can get a widely adopted C and C++ package manager. [...] , but if it were as easy as “npm install skia”, etc. everywhere, It's not just the package manager (the command line tool) ... it's the canonical website source that the tool pulls from. C++ probably won't have a package manager with the same breadth of newer language ecosystems like npm/Nodejs and crates.io/Rust because for 20+ years C++ was developed by fragmented independent communities before a canonical repo website funded by a corporation or non-profit was created. There is no C++ institution or entity with industry-wide influence that's analogous to Joyent (Nodejs & npm) or Mozilla (Crates.io & cargo) I wrote 2 previous linked comments about this different timeline: https://news.ycombinator.com/item?id=24846012 https://news.ycombinator.com/item?id=24846012 Tldr, 2 opposite timelines happened: - C++ for 20+ years of isolated and fragmented development groups creates legacy codebases --> then decades later try to create package manager (vcpkg? Conan? cppget?) that tries to attracts those disparate groups --> thus "herding cats" is an uphill challenge - npm and crates.io exist at the beginning of language adoption allowing the ecosystem to grow around those package tools and view them as canonical

coder543 6y ago
Go has a perfectly good package manager that works with sources hosted on GitHub and other sites -- there isn't any centralized place for people to publish sources, unlike the other package managers you mentioned. Go's package manager also came years after the language became widely used, and it is now very widely adopted according to the most recent survey[0]. I think C++ could have a good, unified package management story. It would just require the major stakeholders to all care enough to make it happen, which seems to be the missing piece here. [0]: https://blog.golang.org/survey2020-results#TOC_8 https://blog.golang.org/survey2020-results#TOC_8.
- jasode 6y ago
  >Go's package manager also came years after the language became widely used, and it is now very widely adopted according to the most recent survey[0]. Are you talking about "pkg.go.dev" and the "go get" command? Isn't there some path dependence in the history of events that's not comparable to C++? Consider: - Go language: created by Google Inc - "go get" syntax for package download designed and created by Google Inc - "pkg.go.dev" funded by Google Inc and highlighted on "golang.org" website that's also run by Google Inc. There is no business entity or institution in the C++ world that's analogous to Google's influence for Go + golang.org + "go get" + pkg.go.dev. >It would just require the major stakeholders to all _care_ enough to make it happen, But it's easier to care if there was an influential C++ behemoth that captured everyone's mindshare to move the entire ecosystem forward. C++ has no such "industry leader" that dictates (or heavily influences) technical direction from the top down.
  - coder543 6y ago
    > Are you talking about "pkg.go.dev" and the "go get" command? No. I'm not talking about either of those. Your whole comment is, unfortunately, irrelevant. pkg.go.dev is not a package repo. It's just a place for documentation to be rendered. It renders documentation from third party hosted code, such as on GitHub or elsewhere. "go get" predates Go Modules, which is the current package management system. The whole original design of "go get" was to simply download code from somewhere on the internet, and place it in the right spot of the $GOPATH. This has nothing to do with a proper versioned package manager like Go Modules. AFAIK, "go get" was also never really designed for Google's internal use cases. They use a monorepo that was perfectly content with $GOPATH, and all their code was developed in the monorepo to begin with. There was nothing for them to "go get", except for the rare outside dependency that they were embedding into their monorepo, I would imagine. I've never worked for Google, these are just things I hear about. Go Modules was also not designed for Google. It was designed for the community, based on findings from community developed package managers for Go. Google has no real use for it — again, they use a monorepo. Nowadays, "go get" can be used with Go modules, but in practice, it feels like it almost never is. Maybe someone would use that command to upgrade an existing dependency, instead of editing the `go.mod` file to change the version there? So, your comment just shows that you haven't researched this enough. Yes, Go Modules was still guided by Googlers, who were even more in control of the language direction back then than they are now. Yes, change always causes some drama. But, I'm not really here to explain the history of Go package management... I'm just saying that C++ could have a nice, distributed package management system, it would just require the major stakeholders to all care and work together on it. The ISO C++ language committee is a finite number of people. They are the major stakeholders, as far as the language direction is concerned. If they didn't have the power to enact major language changes, we wouldn't be here talking about C++20. The stakeholders for Go were able to develop a package manager that is distributed (an idea compatible with how all C++ code is scattered across the web these days), and that achieved broad adoption, and this was some years after the language went into wide use. It’s an extremely relevant analogue for C++ to study, if the committee members wanted a package manager badly enough. > But it's easier to care if there was an influential C++ behemoth that captured everyone's mindshare to move the entire ecosystem forward. C++ has no such "industry leader" that dictates (or heavily influences) technical direction from the top down. You edited this in while I was replying, but I agree entirely. Getting the committee to agree to a package management solution would be much more difficult than having a single behemoth guide the decision. Does that mean it is impossible and therefore no one could do it? Everyone here talks like it is impossible, but it doesn't really seem to be.
- dgellow 6y ago
  Go has a small dedicated team that develops and designs the language. They take some input from the broader community but are still the one who decides how things evolve. They decided at some point that go modules was the way to go and everybody followed, because they are the authority who decides how Go evolves. C++ does not have an equivalent, it's completely decentralized which results in more messy situation. As a result you have an open market where different people try to build different tools and approaches for their own problems, then try to get others to use them (similar to what Go had before go modules, we had lot of package managers to chose from at the time). Instead of a top down decision it's a negotiation between the various actors. But the last thing we need is for the C++ standards committee to standardize a package manager. That would take forever to do, would result in a messy tool that tries to compromise with all the actors in some ways, make it very hard and slow to evolve over time and would likely result in a lot of pain, etc.
  - coder543 6y ago
    > C++ does not have an equivalent, it's completely decentralized which results in more messy situation. That is the role of the ISO C++ committee, is it not? They are the major stakeholders. They would just have to care enough. They cared enough to release C++20, didn't they? It's not like they never get anything done, which seems to be the implication a lot of people make in this discussion. > Instead of a top down decision it's a negotiation between the various actors. My understanding is that the various committee members represent the disparate interests of the broader C++ community. I agree it would be very much like a negotiation. That doesn't mean that it can't be done. This whole thread is discussing things that have been done by the C++ committee: C++20. > But the last thing we need is for the C++ standards committee to standardize a package manager. That would take forever to do, would result in a messy tool that tries to compromise with all the actors in some ways, make it very hard and slow to evolve over time and would likely result in a lot of pain, etc. You just summarized my feelings about C++ in general. I would much rather people use Rust or Go or any number of other languages instead of C++, depending on project needs. Such opinions are rarely taken well in threads like this, though, so... I've been trying to be optimistic and point out that C++ could get package management. If the C++ committee process works well, then the package manager should also end up turning out well. I'll leave the reader to decide how well they think the long term direction and guidance of the C++ standard has been going and apply that to their feelings of a hypothetical future package manager.
- humanrebar 6y ago
  Do the Go sources on GitHub use waf, make, CMake, bazel, or something entirely bespoke? Or is a common build system assumed?
  - coder543 6y ago
    Go just uses the Go build system, which is common to all Go projects, so... it assumes a common build system. Some people do occasionally use Bazel or other build systems on top of the Go build system for complicated monorepos.
    - humanrebar 6y ago
      Right. C++ has a chicken-and-the-egg problem in that neither its build not packaging ecosystem have even de facto standards. GitHub URLs don't solve either problem.
      - coder543 6y ago
        I think everyone agrees that a common build system is a necessary step if any of this is going to work. Thinking about how much or how little would be required beyond a common build system in order to get a working package management system is still a valid thing to do.
        humanrebar 6y ago
        I expect it is necessary to keep build configuration portable with respect to packaging and environment configuration. In other words, I expect downloading from URLs in Makefiles and CMakeLists to be a local maximum. Keeping a parallel set of instructions or metadata that includes specific URLs and such might work, though. As long as you can skip all that when a system package, filesystem path, or git submodule is more appropriate.
mkoubaa 6y ago
ABI makes this hard for c++
- dfgdghdf 6y ago
  Build from source
  - TeMPOraL 6y ago
    Then give me a package manager that can handle cross-compilation well. Currently, it seems almost nobody is taking that into account when packaging their wares for consumption by CMake, or distribution by Conan. Or if they do give it some thought, it always ends up making dubious assumptions, like "Clang == Linux", or "MSVC == Windows".
    - bluGill 6y ago
      I have one at work that does okay. If your project is based on cmake I can create the package very quickly, though most projects still don't create a cmake configuration file. If your project isn't cmake - well at best a day, and often I will spend weeks fighting your half baked build system that doesn't understand the common things I want to do. (in practice autotools projects have the options to cross compile but it doesn't actually work...)
    - maccard 6y ago
      CMake + vcpkg [0] does cross compilation, I've used it mynself. It's pretty good! [0] https://stackoverflow.com/questions/58777810/how-to-integrate-vcpkg-in-linux-with-cross-build-toolchain-as-well-as-sysroot https://stackoverflow.com/questions/58777810/how-to-integrat...
    - nicoburns 6y ago
      Rust/Go seem to manage this just without issues.
      - deleted 6y ago
        [deleted]

by jasode 6y ago

coder543 6y ago

Go has a perfectly good package manager that works with sources hosted on GitHub and other sites -- there isn't any centralized place for people to publish sources, unlike the other package managers you mentioned. Go's package manager also came years after the language became widely used, and it is now very widely adopted according to the most recent survey[0]. I think C++ could have a good, unified package management story. It would just require the major stakeholders to all care enough to make it happen, which seems to be the missing piece here. [0]: https://blog.golang.org/survey2020-results#TOC_8 https://blog.golang.org/survey2020-results#TOC_8.

jasode 6y ago
>Go's package manager also came years after the language became widely used, and it is now very widely adopted according to the most recent survey[0]. Are you talking about "pkg.go.dev" and the "go get" command? Isn't there some path dependence in the history of events that's not comparable to C++? Consider: - Go language: created by Google Inc - "go get" syntax for package download designed and created by Google Inc - "pkg.go.dev" funded by Google Inc and highlighted on "golang.org" website that's also run by Google Inc. There is no business entity or institution in the C++ world that's analogous to Google's influence for Go + golang.org + "go get" + pkg.go.dev. >It would just require the major stakeholders to all _care_ enough to make it happen, But it's easier to care if there was an influential C++ behemoth that captured everyone's mindshare to move the entire ecosystem forward. C++ has no such "industry leader" that dictates (or heavily influences) technical direction from the top down.
- coder543 6y ago
  > Are you talking about "pkg.go.dev" and the "go get" command? No. I'm not talking about either of those. Your whole comment is, unfortunately, irrelevant. pkg.go.dev is not a package repo. It's just a place for documentation to be rendered. It renders documentation from third party hosted code, such as on GitHub or elsewhere. "go get" predates Go Modules, which is the current package management system. The whole original design of "go get" was to simply download code from somewhere on the internet, and place it in the right spot of the $GOPATH. This has nothing to do with a proper versioned package manager like Go Modules. AFAIK, "go get" was also never really designed for Google's internal use cases. They use a monorepo that was perfectly content with $GOPATH, and all their code was developed in the monorepo to begin with. There was nothing for them to "go get", except for the rare outside dependency that they were embedding into their monorepo, I would imagine. I've never worked for Google, these are just things I hear about. Go Modules was also not designed for Google. It was designed for the community, based on findings from community developed package managers for Go. Google has no real use for it — again, they use a monorepo. Nowadays, "go get" can be used with Go modules, but in practice, it feels like it almost never is. Maybe someone would use that command to upgrade an existing dependency, instead of editing the `go.mod` file to change the version there? So, your comment just shows that you haven't researched this enough. Yes, Go Modules was still guided by Googlers, who were even more in control of the language direction back then than they are now. Yes, change always causes some drama. But, I'm not really here to explain the history of Go package management... I'm just saying that C++ could have a nice, distributed package management system, it would just require the major stakeholders to all care and work together on it. The ISO C++ language committee is a finite number of people. They are the major stakeholders, as far as the language direction is concerned. If they didn't have the power to enact major language changes, we wouldn't be here talking about C++20. The stakeholders for Go were able to develop a package manager that is distributed (an idea compatible with how all C++ code is scattered across the web these days), and that achieved broad adoption, and this was some years after the language went into wide use. It’s an extremely relevant analogue for C++ to study, if the committee members wanted a package manager badly enough. > But it's easier to care if there was an influential C++ behemoth that captured everyone's mindshare to move the entire ecosystem forward. C++ has no such "industry leader" that dictates (or heavily influences) technical direction from the top down. You edited this in while I was replying, but I agree entirely. Getting the committee to agree to a package management solution would be much more difficult than having a single behemoth guide the decision. Does that mean it is impossible and therefore no one could do it? Everyone here talks like it is impossible, but it doesn't really seem to be.
dgellow 6y ago
Go has a small dedicated team that develops and designs the language. They take some input from the broader community but are still the one who decides how things evolve. They decided at some point that go modules was the way to go and everybody followed, because they are the authority who decides how Go evolves. C++ does not have an equivalent, it's completely decentralized which results in more messy situation. As a result you have an open market where different people try to build different tools and approaches for their own problems, then try to get others to use them (similar to what Go had before go modules, we had lot of package managers to chose from at the time). Instead of a top down decision it's a negotiation between the various actors. But the last thing we need is for the C++ standards committee to standardize a package manager. That would take forever to do, would result in a messy tool that tries to compromise with all the actors in some ways, make it very hard and slow to evolve over time and would likely result in a lot of pain, etc.
- coder543 6y ago
  > C++ does not have an equivalent, it's completely decentralized which results in more messy situation. That is the role of the ISO C++ committee, is it not? They are the major stakeholders. They would just have to care enough. They cared enough to release C++20, didn't they? It's not like they never get anything done, which seems to be the implication a lot of people make in this discussion. > Instead of a top down decision it's a negotiation between the various actors. My understanding is that the various committee members represent the disparate interests of the broader C++ community. I agree it would be very much like a negotiation. That doesn't mean that it can't be done. This whole thread is discussing things that have been done by the C++ committee: C++20. > But the last thing we need is for the C++ standards committee to standardize a package manager. That would take forever to do, would result in a messy tool that tries to compromise with all the actors in some ways, make it very hard and slow to evolve over time and would likely result in a lot of pain, etc. You just summarized my feelings about C++ in general. I would much rather people use Rust or Go or any number of other languages instead of C++, depending on project needs. Such opinions are rarely taken well in threads like this, though, so... I've been trying to be optimistic and point out that C++ could get package management. If the C++ committee process works well, then the package manager should also end up turning out well. I'll leave the reader to decide how well they think the long term direction and guidance of the C++ standard has been going and apply that to their feelings of a hypothetical future package manager.
humanrebar 6y ago
Do the Go sources on GitHub use waf, make, CMake, bazel, or something entirely bespoke? Or is a common build system assumed?
- coder543 6y ago
  Go just uses the Go build system, which is common to all Go projects, so... it assumes a common build system. Some people do occasionally use Bazel or other build systems on top of the Go build system for complicated monorepos.
  - humanrebar 6y ago
    Right. C++ has a chicken-and-the-egg problem in that neither its build not packaging ecosystem have even de facto standards. GitHub URLs don't solve either problem.
    - coder543 6y ago
      I think everyone agrees that a common build system is a necessary step if any of this is going to work. Thinking about how much or how little would be required beyond a common build system in order to get a working package management system is still a valid thing to do.
      - humanrebar 6y ago
        I expect it is necessary to keep build configuration portable with respect to packaging and environment configuration. In other words, I expect downloading from URLs in Makefiles and CMakeLists to be a local maximum. Keeping a parallel set of instructions or metadata that includes specific URLs and such might work, though. As long as you can skip all that when a system package, filesystem path, or git submodule is more appropriate.

mkoubaa 6y ago

ABI makes this hard for c++

dfgdghdf 6y ago
Build from source
- TeMPOraL 6y ago
  Then give me a package manager that can handle cross-compilation well. Currently, it seems almost nobody is taking that into account when packaging their wares for consumption by CMake, or distribution by Conan. Or if they do give it some thought, it always ends up making dubious assumptions, like "Clang == Linux", or "MSVC == Windows".
  - bluGill 6y ago
    I have one at work that does okay. If your project is based on cmake I can create the package very quickly, though most projects still don't create a cmake configuration file. If your project isn't cmake - well at best a day, and often I will spend weeks fighting your half baked build system that doesn't understand the common things I want to do. (in practice autotools projects have the options to cross compile but it doesn't actually work...)
  - maccard 6y ago
    CMake + vcpkg [0] does cross compilation, I've used it mynself. It's pretty good! [0] https://stackoverflow.com/questions/58777810/how-to-integrate-vcpkg-in-linux-with-cross-build-toolchain-as-well-as-sysroot https://stackoverflow.com/questions/58777810/how-to-integrat...
  - nicoburns 6y ago
    Rust/Go seem to manage this just without issues.
    - deleted 6y ago
      [deleted]