4 ms·
I think your question/problem is actually underspecified to be answerable. What exactly do you want? (non-exhaustive list): 1. have your entire system use a n
by eqvinox 6y ago
I think your question/problem is actually underspecified to be answerable. What exactly do you want? (non-exhaustive list):
1. have your entire system use a newer version of some library?
2. have a specific part of your system use a newer version of some library?
3. build a particular package to use a newer version of some library?
4. just get access to the accompanying executables/tools from a newer version of a library?
5. get a whole bunch of versions so you can test your project against them?
It really depends, and, sure, some of these are very hard to do... but also some of these are really hard problems to begin with, so it's not unsurprising the solution is also a bit involved.
(My answers for these cases:)
1. build a package for the newer library from source; either from included packaging or by transplanting packaging from an earlier version. If it doesn't work, this is an indicator that you have a bigger problem and maybe shouldn't be shoehorning this in.
2. If the newer version is a higher SO version, install that and rebuild part of your system to use it. (Because you need to rebuild anyway.) If it's the same SO version you'll need to install it somewhere else and set up LD_LIBRARY_PATH.
3. Just build the library statically and build the package against that.
4. Build the library/tools with static linking.
5. No free lunch, this is a nontrivial problem. Doable with LD_LIBRARY_PATH and PKG_CONFIG_PATH.
- oblio 6y agoI want to: cppm install library-2.0.0-alpha like in every other programming language, and be able to develop my project with it. Why would I ever even want to do 1 or 2? That's the OS package manager's job. The fact that the OS is written in C/C++ is an implementation detail, it shouldn't leak out. The package manager is also not portable, the commands are not the same, the available libraries are limited and frequently incompatible with each other. Your 3, 4, 5 are all manual steps, if you notice. I don't see any mention of a package manager in there :-)
- eqvinox 6y ago> like in every other programming language, and be able to develop my project with it. You're confusing application development with system development. C and C++ are very much aimed at the latter. By the time you're in a situation where you need to mess with a specific version of a library that is included in your host system, something has fundamentally gone wrong at an earlier point. C and C++ don't provide an application-level package manager, and I think this is pretty much intentional. Both languages "want" to build a system, not an application. Case in point: the C standard library is largely specified in POSIX, right next to system tools - not ISO C.
- int_19h 6y agoThe C standard library is entirely specified in the ISO C standard. POSIX qualifies some things, and adds a lot more, but none of that is the C standard library.
- physicsguy 6y agoIt's overstated that that works everywhere though, it certainly doesn't in Python. That's why we've got pip, conda, virtualenv, pyenv, etc. for version and package manaegemnt.
- int_19h 6y agopip + virtualenv fully solve this problem - maybe not in the most comfortable way (which is why there are all those extensions and alternatives), but certainly way better than anything C++ has - and they ship with Python.
- physicsguy 6y agoIt's not even possible to install every python package (and it's dependencies) using pip, which is why Conda exists.
- int_19h 6y agoIf some package is available in the Conda repos, but not in PyPI, that's down to its author choosing to support one but not the other. Ever since wheels became a thing, I can't think of anything reasonable that's impossible to do via pip when it comes to packaging a library.