in a way apt and yum are package manager for c++
Your development, on the other hand, will depend on a different set of dependency libraries (and this must be reproducible!). This may include stuff like having several different versions of a library (for different projects or different branches or build configs of the same project). This set of libraries will sometimes conflict with what you need for the apps the OS provides.
Because you never want to break your day-to-day applications supported by the OS package manager, you'll need a different way of installing your depepdency libs. This is what language package managers do.
Right now for C and C++ the alternatives are 1) bundling it with your source 2) use version control (e.g. git submodules) 3) make install --prefix=$HOME/foo and configure build for that 4) single header file libraries. None of these work particularly well compared to a proper development package manager like Cargo.
IMO you use submodules only for libraries not already included in your package manager.
When developing software, you need both installed. Not every distro has -dev packages to install headers.
> IMO you use submodules only for libraries not already included in your package manager.
This approach is full of problems, most importantly that this isn't reliably reproducible (without using docker images or something for a reproducible environment). Your package manager may have different libs or different versions of libs than another developer's package manager.
But the bigger issue is version requirements mismatches. Say your web browser (or other must-have app) requires libwidget-1.0, but you're writing an app that needs libwidget-2.0 or libwidget-0.8 or both (e.g. your latest supported release was 0.8 and next release is 2.0). You can't install 2.0 or 0.8 because it would break an app you need for daily work.
Using your distro package manager for development is a partial solution at best.
Really? I would be surprised if every distro didn't have a mechanism to install the headers and static libraries for all of its dynamic library packages. How would the distro's own build process work otherwise?
> But the bigger issue is version requirements mismatches.
This is the killer. Distros are based on the idea that there should be only one version of any package installed at once. A development package manager needs to be able to handle many.
This feels like it should be relatively straightforward to add to distro package managers, though. You would need a package-space concept analogous to a container - a consistent set of packages separate from the host's, and some way to run a build process within it. So i can say:
dnf create-pkgcontainer ~/dev/myproject
dnf --pkgcontainer ~/dev/myproject install zlib-devel-1.2.8
dnf pkgcontainer-run ~/dev/myproject make
It's a pain in the ass when you need to enter a "blessed" environment to build your project. By "blessed", I mean a container environment, a chroot or just some environment variables that need to be set.
> dnf pkgcontainer-run ~/dev/myproject make
The issue with this kind of builds is that they integrate poorly with your $EDITOR (or IDE). When I run a build, I want the results to be piped back to my editor so I can comfortably jump to the files with errors and warnings in them.
And it's not only the build, it's also running your application, running the debugger, static analysis, linters, etc. Requiring a special environment will introduce friction to all of these.
Additionally, your suggestion of using "dnf" would require every developer in the project to use an OS where "dnf" runs. Builds should be reproducible as much as possible without depending on the OS.
Development package managers solve lots of these problems, although having a package manager for every language is an issue.
apt and yum are completely hostile to reproducible builds.
> in a way apt and yum are package manager for c++