6 ms·

Qt 6 will provide additional libraries via Conan package manager

42 points by alaenix 6y ago

mister_hn 6y ago
oh yes!
de_watcher 6y ago
CMake and qmake is not enough. Adding Ninja...
- samsaga2 6y ago
  Still not enough... adding Conan and QML...
- barumi 6y ago
  > 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.
mkl 6y ago
This seems a bit strange. Conan's client is open source, and the repositories are decentralised, but the repository server it all depends on, JFrog Artifactory, is proprietary.
- alaenix 6y ago
  It's the same with npm for Node.js, there is a company behind the package manager.
- bbatha 6y ago
  They have an open source just conan server [1] and artifactory has a community edition which is open source [2]. 1: https://docs.conan.io/en/latest/uploading_packages/running_your_server.html https://docs.conan.io/en/latest/uploading_packages/running_y... 2: https://jfrog.com/open-source/ https://jfrog.com/open-source/
eznzt 6y ago
How about you switch to a free licence such as a two-clause BSD or an MIT licence?
- johannes1234321 6y ago
  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/ 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 ...)
  - eznzt 6y ago
    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?
    - detaro 6y ago
      "They" (Qt Company) are a commercial enterprise that mostly makes its money from license sales. Relicensing as MIT would be terrible for them. From their product policy you can clearly tell that even LGPL isn't working as they would like, but they can't get rid of that, so they focus in fields that don't like LGPL either. That's of course annoying for those of us who don't optimize for "what makes them money", but for "how can we build software best"...
    - johannes1234321 6y ago
      How do you know it would have died? - Mind that their business is in embedded stuff, an area where Electron is no competition (putting a bit more hardware in and embedding android might be competition, but Qt runs on quite small systems) https://www.qt.io/product/develop-software-microcontrollers-mcu https://www.qt.io/product/develop-software-microcontrollers-... As an outsider it seems like the "Desktop" side seems to be a marketing vehicle, but not their bet for business (see also push for QML over QWidgets - less integration with desktop and less "native" looks, but working on cheaper hardware)
AshamedCaptain 6y ago
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 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.
- doliveira 6y ago
  Isn't Docker a thing mainly due to the hassle that it is to manage libraries and headers in C/C++?
  - yokaze 6y ago
    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 bundler, java classpaths?... but I still can mess up the system. And it isn't like there are different ways how it is then solved. 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.
    - doliveira 6y ago
      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.

42 points by alaenix 6y ago

mister_hn 6y ago

oh yes!

de_watcher 6y ago

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

samsaga2 6y ago
Still not enough... adding Conan and QML...
barumi 6y ago
> 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.

mkl 6y ago

This seems a bit strange. Conan's client is open source, and the repositories are decentralised, but the repository server it all depends on, JFrog Artifactory, is proprietary.

alaenix 6y ago
It's the same with npm for Node.js, there is a company behind the package manager.
bbatha 6y ago
They have an open source just conan server [1] and artifactory has a community edition which is open source [2]. 1: https://docs.conan.io/en/latest/uploading_packages/running_your_server.html https://docs.conan.io/en/latest/uploading_packages/running_y... 2: https://jfrog.com/open-source/ https://jfrog.com/open-source/

eznzt 6y ago

How about you switch to a free licence such as a two-clause BSD or an MIT licence?

johannes1234321 6y ago
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/ 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 ...)
- eznzt 6y ago
  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?
  - detaro 6y ago
    "They" (Qt Company) are a commercial enterprise that mostly makes its money from license sales. Relicensing as MIT would be terrible for them. From their product policy you can clearly tell that even LGPL isn't working as they would like, but they can't get rid of that, so they focus in fields that don't like LGPL either. That's of course annoying for those of us who don't optimize for "what makes them money", but for "how can we build software best"...
  - johannes1234321 6y ago
    How do you know it would have died? - Mind that their business is in embedded stuff, an area where Electron is no competition (putting a bit more hardware in and embedding android might be competition, but Qt runs on quite small systems) https://www.qt.io/product/develop-software-microcontrollers-mcu https://www.qt.io/product/develop-software-microcontrollers-... As an outsider it seems like the "Desktop" side seems to be a marketing vehicle, but not their bet for business (see also push for QML over QWidgets - less integration with desktop and less "native" looks, but working on cheaper hardware)

AshamedCaptain 6y ago

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

doliveira 6y ago
Isn't Docker a thing mainly due to the hassle that it is to manage libraries and headers in C/C++?
- yokaze 6y ago
  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 bundler, java classpaths?... but I still can mess up the system. And it isn't like there are different ways how it is then solved. 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.
  - doliveira 6y ago
    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.