Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Qt 6 will provide additional libraries via Conan package manager

qt.io

Post reply on HN
Print view View original

31–37 of 37 posts

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

#31

Post by barumi »

doliveira wrote: post #11
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…

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

The value of Docker is not packaging per se. It's like a linux installer: yeah it's great that they come bundled ina neat ISO image that you can burn/copy/run in place, but that's not it's value proposition. It's value proposition is that you have a self-contained software packages that can be executed at will free from side-effects.

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

#32

Post by barumi »

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.

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

No, it's not. It's exclusively derived from the fact that there is no package manager. Python has a few package managers. Node.js also has package managers, and Rust has too. In C or C++ the only package manager there is is a linux distro's own generic package manager, which isn't exactly designed to handle independent projects.

There is no coincidence in the fact that node.js's npm and conan are services offered by private for-profit companies which have a free tier and paid tier targeting enterprise customers. It's no coincidence because packaging and distribution is a generic software engineering need that is not tied to a specific programming language, and is value-added that, done right, is worth paying for.

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

#33

Post by barumi »

de_watcher wrote: post #3

CMake and qmake is not enough. Adding Ninja...

> CMake and qmake is not enough. Adding Ninja...

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.

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

#34

Post by barumi »

flohofwoe wrote: post #19
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…

"Most platforms" unfortunately excludes Windows, which is too popular to ignore.

Among the available platforms, Windows is by far the less picky about libraries and project setup. You pretty much only need to dump all interface headers in any part of your file system, dump your libraries somewhere else, and then point your project files to it. Afterwards you just need to ensure you nearly bundle your DLLs, and you're all set.

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

#35

Post by barumi »

mook wrote: post #21
tarruda wrote: post #20

Earlier quoted context omitted.

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.

> Linux package managers (that I'm aware of) tend to dislike keeping multiple versions of development headers around, though;

They really don't. At most, those doing the packaging lack the insight to allow users to install separate versions of the same package. You only need to allow your package to not reuse another release's path, and allow users to use a generic major/minor version of a package, and that's it.

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

#36

Post by yokaze »

barumi wrote: post #28
yokaze wrote: post #13

Earlier quoted context omitted.

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 prop…

> You are free to put together your company's PPA, and just package your stuff as you see fit.

I think, I've addressed that point and it's downsides.

> If you're in a "professional context" then you're already in the business of packaging and distributing software packages.

Nowadays, you often aren't. A lot of companies switch to the software-as-a-service model and it's distributing and packaging and distribution are two of the major problems solved by that.

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

#37

Post by flohofwoe »

barumi wrote: post #34
flohofwoe wrote: post #19

Earlier quoted context omitted.

"Most platforms" unfortunately excludes Windows, which is too popular to ignore.

Among the available platforms, Windows is by far the less picky about libraries and project setup. You pretty much only need to dump all interface headers in any part of your file system, dump your libraries somewhere else, and then point your project files to it. Afterwards you just need to ensure you nearly bundle your DLLs, and you're all set.

Sure, but you get that sort of "freedom" on any other platform too. Unlike UNIX-y operating systems, Windows has no notion of a standard location for headers and libraries which package managers and compiler toolchains all agree on.
Post reply on HN