Qt 6 will provide additional libraries via Conan package manager • Hacker News Board

Re: Qt 6 will provide additional libraries via Conan package manager

#21

Post by mook » Wed, Oct 28, 2020, 3:31 PM UTC

tarruda wrote: post #20

detaro wrote: post #15

Earlier quoted context omitted.

Your system package manager typically also sucks for keeping multiple versions/variants of libraries around, and library developers aren't particularly interested in providing packages for many different systems. Not all platforms even have a system package manager you can easily add your own packages to.

Linux package managers have no problem with multiple versions of a library: https://unix.stackexchange.com/a/209712

Linux package managers (that I'm aware of) tend to dislike keeping multiple versions of development headers around, though; they have no issues keeping multiple versions of the libraries themselves. That seems relevant in a discussion about a development library.

I understand that nix might be a notable exception here.

Re: Qt 6 will provide additional libraries via Conan package manager

#22

Post by chriswarbo » Wed, Oct 28, 2020, 3:44 PM UTC

detaro wrote: post #15

AshamedCaptain wrote: post #10

I really don't understand the idea of a C/C++-specific package manager. C is the baseline API for most systems. Your system package manager is already installing C/C++ libraries and headers. Most platforms even have standard paths for storing C/C++ headers and libraries. 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 i…

Your system package manager typically also sucks for keeping multiple versions/variants of libraries around, and library developers aren't particularly interested in providing packages for many different systems. Not all platforms even have a system package manager you can easily add your own packages to.

I think Nix does a pretty good job at this. I've used it on Ubuntu, macOS and NixOS (with the latter two sharing the same system config, with OS-specific pieces tucked into if/else expressions).

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.

Re: Qt 6 will provide additional libraries via Conan package manager

#23

Post by doliveira » Wed, Oct 28, 2020, 4:29 PM UTC

yokaze wrote: post #18

doliveira wrote: post #11

Earlier quoted context omitted.

Isn't Docker a thing mainly due to the hassle that it is to manage libraries and headers in C/C++?

That is not C/C++ specific, from what I saw, most "dynamic" languages picked it up rather more enthusiastically. Resolving the conflict of different library dependencies that arises in almost all languages. And with docker I can solve it in a uniform way. If you install something in the system, it will mess it up for others. Some languages do have "native" ways to avoid that, e.g. python has virtualenv, ruby has bund…

Honestly that all seems to mostly derive from C/C++ issues, doesn't it? Managing Python and Ruby is pretty easy until you hit a library with OS dependencies.

But I'm there with you, I love Docker. But it is a solution to problems we should not be having after 30-ish years.

Re: Qt 6 will provide additional libraries via Conan package manager

#24

Post by mhh__ » Wed, Oct 28, 2020, 4:58 PM UTC

AshamedCaptain wrote: post #10

I really don't understand the idea of a C/C++-specific package manager. C is the baseline API for most systems. Your system package manager is already installing C/C++ libraries and headers. Most platforms even have standard paths for storing C/C++ headers and libraries. 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 i…

This kind of ignores the realities of some big projects, i.e. managing dependencies automatically in Qt (and in a licence conforming way) is an absolute pain.

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.

Re: Qt 6 will provide additional libraries via Conan package manager

#25

Post by hobby-coder-guy » Wed, Oct 28, 2020, 7:00 PM UTC

AshamedCaptain wrote: post #10

I really don't understand the idea of a C/C++-specific package manager. C is the baseline API for most systems. Your system package manager is already installing C/C++ libraries and headers. Most platforms even have standard paths for storing C/C++ headers and libraries. 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 i…

Couldn't care less. Why do people keep doing this?

Re: Qt 6 will provide additional libraries via Conan package manager

#26

Post by yokaze » Wed, Oct 28, 2020, 8:28 PM UTC

doliveira wrote: post #23

yokaze wrote: post #18

Earlier quoted context omitted.

That is not C/C++ specific, from what I saw, most "dynamic" languages picked it up rather more enthusiastically. Resolving the conflict of different library dependencies that arises in almost all languages. And with docker I can solve it in a uniform way. If you install something in the system, it will mess it up for others. Some languages do have "native" ways to avoid that, e.g. python has virtualenv, ruby has bund…

Honestly that all seems to mostly derive from C/C++ issues, doesn't it? Managing Python and Ruby is pretty easy until you hit a library with OS dependencies. But I'm there with you, I love Docker. But it is a solution to problems we should not be having after 30-ish years.

> Managing Python and Ruby is pretty easy until you hit a library with OS dependencies.

And that's why there is practically only one solution to solve it in either language (/sarcasm off).

Docker in my mind wasn't a sensible choice for compiled languages prior multi-stage builds, or better buildkit.

> Honestly that all seems to mostly derive from C/C++ issues, doesn't it?

It derives from having binary libraries, and a plethora of ABIs. And contrary to Go advocats and docker fans, I do believe they have their place. There is no perfect technical solution, there is always a trade-off.

With compiled languages you deliver binaries. A development / delivery split is expected. The intermediate data (object files + debug data) often need a lot of storage, and are not supposed to be shipped directly. With a binary interface (ABI), you simply can ship your shared object or executable individually.

With statically linked/compiled binaries, you have to ship every binary using the fixed library. Or in case of docker, it will likely affect a lower layer which will invalidate all the upper layers of each docker image using said library.

So a couple of bytes delta in a couple of KB library can mean a couple of KB binary package, or a couple of multi-mb binaries or layers containing all the upper parts.

Your OS is most likely working with shared objects/DLLs and their ABIs, and there is a reason for that. Your use-case might not demand that, and that is okay, but it doesn't invalidate that there is a sensible reason for doing it the way it is done.

Re: Qt 6 will provide additional libraries via Conan package manager

#27

Post by empyrical » Wed, Oct 28, 2020, 10:16 PM UTC

eznzt wrote: post #14

johannes1234321 wrote: post #9

Earlier quoted context omitted.

If you pay them enough ... they seem to struggle and are searching for ways to get revenues. 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 ...)

With Electron (MIT licence) the writing has been on the wall for Qt for years now. They are on borrowed time. 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?

> Electron (MIT licence)

It's not 100% MIT. Chromium's Blink renderer has LGPLv2.1 code going back to the KDE KHTML days, such as some of the code for the DOM:

https://github.com/chromium/chromium/blob/master/third_party...

Very rough way of going about it, but searching for files with copyright headers crediting KDE shows 832 files

https://github.com/chromium/chromium/search?l=C%2B%2B&q=kde....

Re: Qt 6 will provide additional libraries via Conan package manager

#28

Post by barumi » Thu, Oct 29, 2020, 2:09 AM UTC

yokaze wrote: post #13

AshamedCaptain wrote: post #10

I really don't understand the idea of a C/C++-specific package manager. C is the baseline API for most systems. Your system package manager is already installing C/C++ libraries and headers. Most platforms even have standard paths for storing C/C++ headers and libraries. 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 i…

Sure there is a barrier and it is the same as for other programming languages. 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…

> If you rely on your package manager, you are basically stuck with whatever was in the previous LTS of ubuntu when it was shipped.

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.

Re: Qt 6 will provide additional libraries via Conan package manager

#29

Post by barumi » Thu, Oct 29, 2020, 2:19 AM UTC

mhh__ wrote: post #24

AshamedCaptain wrote: post #10

I really don't understand the idea of a C/C++-specific package manager. C is the baseline API for most systems. Your system package manager is already installing C/C++ libraries and headers. Most platforms even have standard paths for storing C/C++ headers and libraries. 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 i…

This kind of ignores the realities of some big projects, i.e. managing dependencies automatically in Qt (and in a licence conforming way) is an absolute pain. 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 us…

> QMake is old but functional, CMake is more up to date but a total pain if you use it irregularly.

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.

Re: Qt 6 will provide additional libraries via Conan package manager

#30

Post by barumi » Thu, Oct 29, 2020, 2:25 AM UTC

detaro wrote: post #15

AshamedCaptain wrote: post #10

I really don't understand the idea of a C/C++-specific package manager. C is the baseline API for most systems. Your system package manager is already installing C/C++ libraries and headers. Most platforms even have standard paths for storing C/C++ headers and libraries. 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 i…

Your system package manager typically also sucks for keeping multiple versions/variants of libraries around, and library developers aren't particularly interested in providing packages for many different systems. Not all platforms even have a system package manager you can easily add your own packages to.

> Your system package manager typically also sucks for keeping multiple versions/variants of libraries around

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.