Hey,
Since Qt has its own Conan/Artifactory setup
<https://www.qt.io/blog/installing-qt-via-conan-package-manager>, maybe
it would be viable to have some different SIMD setups available as
options for the Qt package?
This would require Conan as a dependency, of course. On most systems
that means Python (Conan 1.x supports py2 still, the upcoming Conan 2.0
with all its breaking changes will require py3, iirc), but on Windows
they have .exe versions available <https://conan.io/downloads.html>.
I think this would have little impact in the overall build process.
`conan install qt <options>` and just point your project to look for Qt
in ~/.conan... With Qt Creator should be just creating a new kit. If the
Windows installer for Qt helped with this, even better.
Rui
Às 13:30 de 24/01/2022, Konrad Rosenbaum escreveu:
Hi,
On 23/01/2022 19:39, Thiago Macieira wrote:
I expect that most of those tools are therefore simply using whatever
binaries
they obtained from The Qt Company and didn't rebuild from source. I
think this
is how we at Intel do for the installers for the oneAPI SDK on Linux
and macOS
(the Windows installer got rewritten a few years ago).
Correct. Only a handful of application developers know how to compile
the entire framework and (esp. on Windows) a lot of them would not
even have the idea to do it. Some of my Windows-based colleagues would
panic if I told them to compile their frameworks. I have had paid
customer projects to help them compile Qt for some OS version where
binaries were not readily available.
Then there are bastards like me who know perfectly well how to compile
Qt, who compile all kinds of large programs all the time, but refuse
to do so with Qt because I am too lazy to tune my build process, I
think it takes too long and I like the excuse of using "the standard
configuration"... ;-)
So if my proposal had been in effect for those releases, it's quite
likely the
tools wouldn't have run on your 13+-year-old computer.
But it isn't. We're talking about the next release, 6.4. There won't
be any
tools built with it until the second half of this year, and commercial
customers may even want to wait for the LTS release after that.
And what makes you think that we stingy, cheap and lazy bastards will
buy a new computer to replace this outdated piece of scrap metal this
year when we haven't done so in more than 10 years? ;-)
The cruel fact is that around 2010 computers got so darn efficient
that you can run a moderately good machine from slightly before 2010
with minor upgrades to this day and call it "the kid's computer" or
even your "main workstation" without blushing. I know plenty of people
(both laymen and CS professionals) who run such old hardware (or
worse) and don't even notice that it is old - if I hadn't looked it up
I would have sworn my workstation is less than 6 years old.
[Yes, as someone who's income depends on people buying the newest
chips the irony of not replacing my own computer in >10 years is not
entirely lost on me...]
Speaking of LTS: with LTS not available to Open Source users anymore -
sticking with older versions of Qt is not exactly a good option
either. Unless I restrict myself to Qt 5.15 until I'm satisfied all my
downstream users are likely to have bought a new computer (if they are
as stingy as I am, then Qt7 will be close to being released before
that happens).
On Linux, we can have the multiple versions. I proposed a minimum of
v2 and an
option of v3, but we can always choose v1+v2+v3. But I really want v2
and v3
for the critical libraries.
Please please chose v1 as pre-built minimum. There are plenty of v1
systems out there that need to run Qt applications and plenty of
developers who will never re-compile Qt.
If the physical appearance of the "please" makes a difference: Pretty
Please!
I have absolutely no problem with stuff running faster and more
efficient on my two laptops (which are significantly more modern), but
I would have a major problem with it not running at all on my
workstation that I use for 95% of all my Open Source work. And I would
also not like my applications to crash on my downstream user's
computers (which are on average just as old as mine) - every crash
means hours of work for someone (usually me) to find out what the
problem was.
Konrad
_______________________________________________
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
_______________________________________________
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development