Also as a C/C++ guy I could care less if the libraries are written in Brainfuck for what is worth, as long as their API stays usable from C, which is pretty much guaranteed. So the idea of a "C/C++ package manager" seems strange, and even trying to create a barrier where there was none.
If you rely on your package manager, you are basically stuck with whatever was in the previous LTS of ubuntu when it was shipped.
If you want the newest library, then you are either dependent on some external proper packager, or you have to get into packaging yourself. I don't consider picking a random external source something I would do in a professional context.
But if we open up the choice of library versions from "non-standard" versions, the problem becomes a transient one. Team A in location B needs at least version X, but not version Y, team C in location D won't do with version Z.
To give that kind of flexibility, people went for build from source instead (Go, Java,...)
And in every shop I have worked until now, "your package manager" meant usually having to support at least one linux distribution in two versions, Windows and Mac, which do not have a native package manager.
This is not exactly true. You are free to put together your company's PPA, and just package your stuff as you see fit. You know, use the system's package manager to serve your and your user's interests.
> If you want the newest library, then you are either dependent on some external proper packager, or you have to get into packaging yourself. I don't consider picking a random external source something I would do in a professional context.
If you're in a "professional context" then you're already in the business of packaging and distributing software packages.
I don't want to try every single combination of static/shared etc. to find what works, that and deploying the executable, again, should be automated.
QMake is old but functional, CMake is more up to date but a total pain if you use it irregularly. I've never used Conan so I can't comment on it.
It's slightly ridiculous that this is still a pain point when Rust has cargo and D has dub - both of them not perfect, but totally functional and basically painless for the most part.
In my experience it's the exact opposite. Cmake can be a real treat to use, provided you follow the so-called modern cmake approach, and qmake is just an unmaintainable mess of a system.
> I've never used Conan so I can't comment on it.
Conan is pretty much orthogonal to any build system. Conan's responsibility is pretty much limited to managing the project's third-party libraries: it handles downloading their interfaces and libraries, pass their settings, and just integrate them into your project with as little code as possible.
There is indeed some modules for CMake that offer some limited functionality that allows third-party packages to be integrated, such as the ExternalProject module. However, those were an afterthought that only add complexity to a project.
For the latter, the version used varies per project. The former is typically system wide.
For my hobby projects, I indeed use cmake to generate .deb packages which I then use in other projects. For professional development I've never seen this work successfully.
I think of Nix more as a build system than a package manager (and in fact I've come to think of "package managers" as a sub-set of build systems, mostly used to work around deficiencies in Make which make it unsuitable for building whole operating systems via composition of their Makefiles).
One thing that Nix emphasises is that users should not be installing dependencies, like libraries; let alone in a globally visible, ambiguous location like '/usr/lib' (or /usr/bin, etc. if it's a tool that we're depending on). Dependencies are only needed 'ambiently' in a package's build environment; build products can embed references those by absolute path if they like, but they shouldn't be 'propagated' into the final system.
They really don't. At most, what really sucks is the way some projects are bundled. Unfortunately the way Qt has been packaged in Debian/Ubuntu is one of these examples on how not to package software. Qt ships and maintains multiple release versions concurrently, and it's a shame that package managers insist on pretending they only need to have one semver major version installed at all times.
But with docker, I package and isolate the whole OS. So, as a consumer, I do not have to know how to do that for each language, and as a producer, I can do (almost) whatever I want within the container without fearing to mess up other containers or the hosting OS.
Yes, this whole approach has its own downsides. But those things are a plus, I would say.
1: https://docs.conan.io/en/latest/uploading_packages/running_y... 2: https://jfrog.com/open-source/
Your comment makes no sense at all. Both cmake and qmake are competing build systems, and qmake already lost and was superceded by cmake.
Cmake works as a high-level makefile generator, which pretty much outputs the DAG of a project's build targets in any of the supported lower-level systems. Right now it supports Make and also Ninja.
Cmake's support for ninja is a nice-to-have, just like it's support for Visual Studio and Xcode project generation. No cmake user was ever blocked by cmake's lack of support for ninja. In fact, no one barely notices any change if you replace make with ninja. In fact, I was surprised to know that Qt Creator started configuring Cmake projects to use Ninja by default because things just worked the same anyway, and honestly I didn't bothered to change anything because there was no discernible difference at all.
Alternatively they have to go bankrupt, then the agreement with KDE Kicks in and it becomes BSD https://kde.org/community/whatiskde/kdefreeqtfoundation/ (but in that case one has to ensure somebody continues working on it ... no idea if KDAB and KDE have enough manpowwer ...)
I am not saying I like Electron better. I prefer Qt, even though I don't consider it to be native either. But Qt would not have died had they relicenced earlier. It's evident they will have to do it eventually. Why wait until there's no more lunch to be eaten?
