5 ms·

Honestly, C and C++ libraries being annoying to deal with is a Windows-created problem. POSIX systems have pkg-config as the de-facto standard way to find inst

Honestly, C and C++ libraries being annoying to deal with is a Windows-created problem. POSIX systems have pkg-config as the de-facto standard way to find installed (or non-installed, if done correctly) libraries, and all common build systems (including autoconf, CMake, Meson, ...) support this. Meanwhile on Windows you're left with a pile of unpacked library directories somewhere on your disk and everyone does their own thing and it's a clusterf*ck of build system twiddling. And the worst part is that this bleeds over into POSIX systems when Windows-created libraries make a jump over and don't know to stick to the conventions.

sto_hristo 6y ago
But the inherent problem is still the inability to deal with dependencies in a standard and portable way. As you said - pkg-config is standard on POSIX, but the world is bigger than this.
arximboldi 6y ago
This is so true. It is always Windows people trying to bend libraries to make them easy to "install" for them. On Unix installing libraries system-wide was never too much of a hassle, and now with Nix you can have reproducible distinct development environments for each project. I hate that sadly a lot of the projects I work on must also work on Windows, but I'd just hire a Windows person simply to deal with their build system stuff.
- pjmlp 6y ago
  Try having the fun to install something on e.g. Aix.
oblio 6y ago
Yeah, but the thing is, even on POSIX stuff, even without Windows-created libraries, how do you: package-manager install bleeding-edge-library and have it just work? Keep in mind, I don't want to use an entire bleeding edge OS in order to easily get 1 bleeding edge library. Also, how do I do it on another POSIX OS, in a standard way for my development flow?
- 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 ago
    I 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.
eska 6y ago
Oh how I wish that everyone would support pkgconfig! I've been adding pkgconfig support to various libraries, sometimes being shut down or ignored (dangling PRs). Meanwhile cmake etc often write their own proprietary support (find modules and include scripts) instead of just piggybacking on pkgconfig..
pornel 6y ago
When Cargo removed POSIX-only features (running a bash script pre-build), I protested. Who cares about Windows and their mess!? But in retrospect that has been a great decision. The ecosystem has followed and supports Windows without friction. Cargo solves the "pile of unpacked library directories" problem. Crates that use system dependencies know how to use vcpkg or build from source. They will even read Windows registry for you to configure MSVC, so you don't need to run vcvars.bat. The effect is that I can just write stuff on Mac, and my Rust projects mostly "just work" on Windows.
- Measter 6y ago
  I develop on Windows, and my experience has been that unless a crate is specifically written for another platform, they generally work perfectly fine on Windows with two exceptions: 1. Terminal-related functions. This is getting better as cross-platform libraries are made, but Windows has had a generally shite terminal emulator and the more common libraries expected a *nix-style terminal. 2. The crate has a C or C++ dependency.
  - int_19h 6y ago
    The terminal story should be a lot better on Win10 these days, what with ConPTY and VT100 support.
pjmlp 6y ago
Nope, Windows is not the only OS without packing management, and good luck actually using pkg-config on any POSIX platform that isn't a BSD or Linux distribution. Also good luck using it on platforms where using multiple commercial C or C++ compilers, each with its own ABI is current practice.

sto_hristo 6y ago

But the inherent problem is still the inability to deal with dependencies in a standard and portable way. As you said - pkg-config is standard on POSIX, but the world is bigger than this.

arximboldi 6y ago

This is so true. It is always Windows people trying to bend libraries to make them easy to "install" for them. On Unix installing libraries system-wide was never too much of a hassle, and now with Nix you can have reproducible distinct development environments for each project. I hate that sadly a lot of the projects I work on must also work on Windows, but I'd just hire a Windows person simply to deal with their build system stuff.

pjmlp 6y ago
Try having the fun to install something on e.g. Aix.

oblio 6y ago

Yeah, but the thing is, even on POSIX stuff, even without Windows-created libraries, how do you: package-manager install bleeding-edge-library and have it just work? Keep in mind, I don't want to use an entire bleeding edge OS in order to easily get 1 bleeding edge library. Also, how do I do it on another POSIX OS, in a standard way for my development flow?

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 ago
  I 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.

eska 6y ago

Oh how I wish that everyone would support pkgconfig! I've been adding pkgconfig support to various libraries, sometimes being shut down or ignored (dangling PRs). Meanwhile cmake etc often write their own proprietary support (find modules and include scripts) instead of just piggybacking on pkgconfig..

pornel 6y ago

When Cargo removed POSIX-only features (running a bash script pre-build), I protested. Who cares about Windows and their mess!? But in retrospect that has been a great decision. The ecosystem has followed and supports Windows without friction. Cargo solves the "pile of unpacked library directories" problem. Crates that use system dependencies know how to use vcpkg or build from source. They will even read Windows registry for you to configure MSVC, so you don't need to run vcvars.bat. The effect is that I can just write stuff on Mac, and my Rust projects mostly "just work" on Windows.

Measter 6y ago
I develop on Windows, and my experience has been that unless a crate is specifically written for another platform, they generally work perfectly fine on Windows with two exceptions: 1. Terminal-related functions. This is getting better as cross-platform libraries are made, but Windows has had a generally shite terminal emulator and the more common libraries expected a *nix-style terminal. 2. The crate has a C or C++ dependency.
- int_19h 6y ago
  The terminal story should be a lot better on Win10 these days, what with ConPTY and VT100 support.

pjmlp 6y ago

Nope, Windows is not the only OS without packing management, and good luck actually using pkg-config on any POSIX platform that isn't a BSD or Linux distribution. Also good luck using it on platforms where using multiple commercial C or C++ compilers, each with its own ABI is current practice.