Hacker News Reader

Comment by eqvinox | Hacker News Reader

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.

View on HN

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.

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.

The terminal story should be a lot better on Win10 these days, what with ConPTY and VT100 support.

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.

Try having the fun to install something on e.g. Aix.

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

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?

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.

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 :-)

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

The 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.

It'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.

pip + 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.

It's not even possible to install every python package (and it's dependencies) using pip, which is why Conda exists.

If 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.

Install Guix as a package manager on a POSIX system. It really solves these problems.

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.

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.

Reply on news.ycombinator.com