> On 04.05.23 08:52, Maurice Kalinowski via Development wrote: > [...] > > This is the situation we experience in multiple industries still, with an > increasing pressure from multiple angles to get those finally supporting Qt 6. > Hence, things are getting better for C++17 _now_. > [...] > > This actually sounds like an argument for _earlier_ adoption. If Qt, as > an important component in the ecosystem, slows the pace, then OEMs feel > even less pressure to update their toolchains, making the problem worse > for the industry at large. > > The main problem I have with this line of reasoning is that I think it's > the LTS's job to serve those customers that end up in these situations. > So it's not like those customer's can't use Qt, they just can't use the > latest features. But they can't, anyway, because they have such an old > toolchain. I wonder how much of this is customer' requests and how much > of it our desire to move customers off Qt 5? > [Maurice Kalinowski] I don't agree that Qt is slowing it, we are one of the drivers to accelerate. As I said, there are multiple players in this context, Qt being one of them. When we said that we are going to require C++17 for Qt 6, that caused a lot of concerns, as at the time of the announcement not all OS had support for it, the hardware vendors did not even start adding it, over players in this chain were unprepared as well. On the other end of the spectrum we had users, who wanted to use new functionality, but knew it is going to take time until they finally can. Again, we as Qt have been pushing, but things move slowly.
> One way to skin this particular cat would be to keep non-core modules > compatible with the last LTS to give users access to newer features in > those modules without having to update tool-chains. Realistically, most > of the bang we get from a C++20 requirement is in QtBase and, possibly, > QtDeclarative. IIUC, we do this for some part of qtdeclarative and for > qtwebengine already, and, while it's occasionally annoying, it lets us > eat our own dog-food, too. [Maurice Kalinowski] Compatibility of LTS to non-LTS, or how to do versioned released of individual modules is an orthogonal discussion. I think we should not mix those, even though I am a fan of that idea personally. But the release team (amongst others) would hate me for that :) > > Speaking with the tongue of the Qt OSS project, I fail to see how all > this isn't SEP. Users of such OEM boards have several ways to solve the > problem: > - pressure the OEM to support a six-year-old C++ standard [Maurice Kalinowski] You might be mixing OEM with other players. OEMs (the people shipping devices in any shape or form) would love to use latest features as well. They get their BSPs from Tier1 who then get the base BSP from hardware/chipsetvendor who then... > - pay someone (TQtC, KDAB) to build a newer toolchain on top of the old > one, or do in-house [Maurice Kalinowski] In non-regulated industries that is one option, yes. We also checked whether we could be shipping those in parallel. It works for prototyping and potentially development phase, but not for getting approval to ship your device. > - vote with your feet and switch to an OEM that has a better customer > service [Maurice Kalinowski] Again, mixing terminology and unfortunately Qt is only one item in the whole decision process. Maurice -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
