Re: [Development] The sorry state of the Qt6 cross compile experience

[Dominik Holland]

Am 2/24/21 um 4:25 PM schrieb Joerg Bornemann:
> On 2/24/21 12:56 PM, Bogdan Vatra wrote:
>
>> Let me give you another non-android example:
>> You want to create a standalone SDK for linux armhf using yocto. You'll
>> generate the SDK with everything including Qt for host and for
>> target, the sdk
>> is a huge auto extract archive which can be shared with everyone. Can
>> this
>> archive contain only the Qt for the target? Nope because there is no
>> way to
>> know if and where the Qt for host is installed on everyone computers,
>> you also
>> need to know where the Qt for host it is in order to fix the
>> hardcoded paths.
>
Mhh, yocto builds both the host Qt and the target Qt and the SDK archive
will contain both Qt version. But this was already the case for Qt5 as
well. I don't think anything has changed here.

Dominik
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] The sorry state of the Qt6 cross compile experience

[Joerg Bornemann]

On 2/24/21 12:56 PM, Bogdan Vatra wrote:


Let me give you another non-android example:
You want to create a standalone SDK for linux armhf using yocto. You'll
generate the SDK with everything including Qt for host and for target, the sdk
is a huge auto extract archive which can be shared with everyone. Can this
archive contain only the Qt for the target? Nope because there is no way to
know if and where the Qt for host is installed on everyone computers, you also
need to know where the Qt for host it is in order to fix the hardcoded paths.


Thanks. That's looks indeed like a good example that affects more people 
than just a handful of Qt devs. Will add a note to the report and adjust 
the prio.


The alternative approach for this case is to enable QT_BUILD_WITH_TOOLS 
for the yocto build and rely on binfmt_misc to transparently execute arm 
binaries.



Cheers,

Joerg
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

[Development] [Announce] Qt Creator 4.14.1 released

[List for announcements regarding Qt releases and development]

We are happy to announce the release of Qt Creator 4.14.1 !
https://www.qt.io/blog/qt-creator-4.14.1-released

-- 
Eike Ziller
Principal Software Engineer

The Qt Company GmbH
Erich-Thilo-Straße 10
D-12489 Berlin
eike.zil...@qt.io
http://qt.io
Geschäftsführer: Mika Pälsi,
Juha Varelius, Jouni Lintunen
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 
144331 B

___
Announce mailing list
annou...@qt-project.org
https://lists.qt-project.org/listinfo/announce
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

[Development] Stepping down as Qt Virtual Keyboard maintainer

[Mitch Curtis]

Hi.

I would like to formally step down as the maintainer of Qt Virtual Keyboard. I 
initially volunteered to take care of the module, however, with Jarkko Koivikko 
having written most of the module himself, it was never really an accurate 
reflection of its ownership. I have mostly been reviewing Jarkko's changes and 
doing administrative stuff, which I will continue to help out with.

Unsurprisingly, I would like to nominate Jarkko as the maintainer. For a list 
of his changes, see the previous thread nominating him to be an approver:

https://lists.qt-project.org/pipermail/development/2021-January/040908.html

Cheers.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] The sorry state of the Qt6 cross compile experience

[Alexander Nassian]

No, you‘re not. But I already gave up seeing the absolute mess TQC has done 
with Qt6.

Beste Grüße / Best regards,
Alexander Nassian

> Am 24.02.2021 um 12:59 schrieb Bogdan Vatra via Development 
> :
> 
> Anyway, it seems I'm the only one who's bothered by this issues, so, I'll 
> stop 
> complaining.
> 
> Yours,
> BogDan.
> 
> 
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development

-- 










—


bitshift dynamics GmbH
Neudorfer Str. 1, 79541 Lörrach
Registergericht: Amtsgericht Freiburg i. Breisgau, HRB 713747
Geschäftsführer: Alexander Nassian, Markus Pfaffinger


https://bitshift-dynamics.com 

Phone: +49 
762158673 - 0
General support: i...@bitshift-dynamics.com 

Technical support: 
supp...@bitshift-dynamics.com 
Accounting: invo...@bitshift-dynamics.com 

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] The sorry state of the Qt6 cross compile experience

[Bogdan Vatra via Development]

Hi,
> On 2/24/21 9:30 AM, Bogdan Vatra wrote:
> > Do you still believe that I'm one of the few affected by this?
> > Don't you think that everyone who's using cross compiling is affected?
> 
> I have seen cross-compiling folks using the cross-platform abilities of
> Qt to prototype stuff on desktop. The assumption is: most people want to
> have a full desktop Qt anyways.
> 
> You're especially affected because of your focus on Android.
> That's all I'm saying.
> 

Let me give you another non-android example:
You want to create a standalone SDK for linux armhf using yocto. You'll 
generate the SDK with everything including Qt for host and for target, the sdk 
is a huge auto extract archive which can be shared with everyone. Can this 
archive contain only the Qt for the target? Nope because there is no way to 
know if and where the Qt for host is installed on everyone computers, you also 
need to know where the Qt for host it is in order to fix the hardcoded paths.

Now, let's say you want to create another standalone SDK for arm64. When 
you'll generate the new SDK, it will contain another Qt for host and for 
target.

As you said, most of us will also have a full desktop Qt, it means in this 
case you'll endup with 3 identical Qt for you host, unless I'm missing 
something and you don't really need a host Qt build for cross compiling ... 
otherwise is even worse as android shares a single copy of Qt for host.


> > It's a good thing when is done right, check the numbers above. Right now
> > is
> > broken, there is no way to install only the host tools. As long as the bug
> > report has a P2 priority, I'll not hold my breath to see it fixed any time
> > soon, for sure not in 6.1 or in 6.2
> 
> You'll be delighted to learn that the priority is at P3.
> You could put energy into explaining why this is especially important to
> you and many others. But please, it's your call to continue rambling on
> aimlessly instead.

This is what I was trying to do, but it seems I failed big time ... 


Anyway, it seems I'm the only one who's bothered by this issues, so, I'll stop 
complaining.

Yours,
BogDan.


___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] The sorry state of the Qt6 cross compile experience

[Joerg Bornemann]

On 2/24/21 9:30 AM, Bogdan Vatra wrote:


Do you still believe that I'm one of the few affected by this?
Don't you think that everyone who's using cross compiling is affected?


I have seen cross-compiling folks using the cross-platform abilities of 
Qt to prototype stuff on desktop. The assumption is: most people want to 
have a full desktop Qt anyways.


You're especially affected because of your focus on Android.
That's all I'm saying.


It's a good thing when is done right, check the numbers above. Right now is
broken, there is no way to install only the host tools. As long as the bug
report has a P2 priority, I'll not hold my breath to see it fixed any time
soon, for sure not in 6.1 or in 6.2


You'll be delighted to learn that the priority is at P3.
You could put energy into explaining why this is especially important to 
you and many others. But please, it's your call to continue rambling on 
aimlessly instead.


I suggest to create a bug report about the hard-coded paths, explain 
what's wrong. You know the game.


Regarding multi-ABI, there's QTBUG-80943 that tracks this.


Cheers,

Joerg
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] The sorry state of the Qt6 cross compile experience

[Bogdan Vatra via Development]

Hi,

În ziua de marți, 23 februarie 2021, la 22:06:55 EET, Joerg Bornemann a scris:
> On 2/23/21 12:27 PM, BogDan Vatra via Development wrote:
> 
> OK, biting.
> 
> > - first and foremost, we need to waste time to **fully** build and install
> > it for host platform (desktop).
> 
> No, you don't need a full build. You need the tools that are called by
> the build system. The support for creating a "minimal desktop" build
> could be better, sure. But you're one of few affected people.
> 

Let's check some numbers:
bogdan@debian:~/Qt/5.12.10/android_arm64_v8a$ du -sh .
357M.
bogdan@debian:~/Qt/5.12.10/android_arm64_v8a/include$ du -sh .
91M .
So, before we had all ABIs in one place, a single ABI had over 350Mb and  only 
the headers were +25%. Of course there are many other common files not only the 
headers.

bogdan@debian:~/Qt/5.15.2/android$ du -sh .
656M.
5.15.2 has all 4 ABIs in one place (also a few extra modules than 5.12.0).
The conclusion is: having all the ABIs in one place reduced the SDK with +50%! 
656M < 357M * 4

Now let's check 6.0.1. I choose to install only android, and this is what I 
got:
bogdan@debian:~/Qt/6.0.1$ ls
android_arm64_v8a  android_armv7  android_x86  android_x86_64  gcc_64  
sha1s.txt
bogdan@debian:~/Qt/6.0.1$ du -sh .
1,4G.
The conclusion is: 6.0.1 has less than half of the 5.15.2 Qt modules, but it 
has more than twice the size of 5.15.2 for Android.

Let's see how big are the tools
bogdan@debian:~/Qt/6.0.1/gcc_64/bin$ du -sh .
97M .

So, for 100M, you've added +700M.

Do you still believe that I'm one of the few affected by this?
Don't you think that everyone who's using cross compiling is affected?


>  >  Yeah, I know that this was "decided" before TQC
>  > 
>  > switched, overnight, to cmake, but let's face it, it's a BS needed to
> 
> cover
> 
>  > the fact that cmake can't build more than one platform at once.
> 
> Let's face it. It's a good thing to not compile the same set of tools
> over and over again, and it simplifies the build very much.
> 

It's a good thing when is done right, check the numbers above. Right now is 
broken, there is no way to install only the host tools. As long as the bug 
report has a P2 priority, I'll not hold my breath to see it fixed any time 
soon, for sure not in 6.1 or in 6.2

> > - the cross build installation is broken, instead to copy the tools from
> > the QT_HOST_TOOLS folder,  it creates some scripts that has hardcoded
> > paths to QT_HOST_TOOLS which runs the scripts from QT_HOST_TOOLS folder.
> > Of course this makes the installation unusable on another computer. Even
> > the "lib/cmake/Qt6/ qt.toolchain.cmake" contains hardcoded paths...
> 
> Right. The Qt5 qmake build never had any hard-coded paths. Try again.

Well qmake was smart enough to replace the hard-coded paths with the ones 
found in qt.conf
Just to be clear, I'm not the qmake advocate, I'm not saying that qmake is 
better than cmake for all the projects out there, I'm using cmake myself in 
many of my projects. What I'm saying is that qmake being specifically crafted 
for Qt was better than cmake to build Qt.

> 
> > - there is no way to have a standalone cross build installation, we always
> > need to ship the whole desktop installation as well (also patch all the
> > files from cross installation).
> 
> Do interpret this correctly as the second attempt in your mail to kindly
> suggest better support for a minimal desktop build?
> 
> > - android cross compilation is so crippled now.  In Qt 5.x times, we used
> > to have a nice multi ABI build which built all the android ABIs in one go
> > and it created a unified Qt SDK for all these ABIs (same as the Android
> > NDK). In Qt 6, that work was trashed... for the same reason: cmake can't
> > handle multiple platforms at once...
> 
> That's right. We're lacking support for multi-ABI that was hacked into
> the Qt build where we run configure tests for one random architecture
> and use those configure results for all other architectures.
> I consider this a good thing.
> 

How can be a good thing to:
- have twice the size of the Andorid sdk on disk for less modules
- not being able to bundle multiple ABIs in the same package anymore

> > - android cross compilation in Qt 6 takes more time to build one ABI  with
> > less Qt modules than in Qt5 to build all ABIs and all modules...
> 
> And your thorough analysis of the problem is "CMake is BS"?

If you check my email again, you'll see that I didn't said that "CMake is BS", 
I said that the host tools is a BS, and I'll keep believing that until I'll 
see a real benefit.
Having only host tools built without being able to install them makes them 
useless. Even after you'll fix the installation, they are still useless as long 
as the QtSDK will not share other common resources (i.e. headers).
If QtSDK will install only the specific parts of a platform (something like 
Android NDK or debian[1]), then I'll see a real benefit.


Yours,
BogDan.

[1] 

Re: [Development] The sorry state of the Qt6 cross compile experience

[Dominik Holland]

Am 24.02.21 um 08:47 schrieb Bogdan Vatra via Development:


Hi,


You have some valid complaints, but:

BogDan Vatra via Development wrote:

- the cross build installation is broken, instead to copy the tools from
the QT_HOST_TOOLS folder,  it creates some scripts that has hardcoded
paths to QT_HOST_TOOLS which runs the scripts from QT_HOST_TOOLS folder.
Of course this makes the installation unusable on another computer. Even
the "lib/cmake/Qt6/ qt.toolchain.cmake" contains hardcoded paths...

In distribution packaging, that is exactly what we want: in the packaged
cross Qt, use the known paths to our packaged host Qt instead of guessing
them at runtime (and often guessing wrong).


   Most of the people out there are using yocto, buildroot to create a nice
SDKs with all the things they need  which will share with their collages, of
course having hardcoded paths will break these SDKs. Not even with conan will
not work for the same reason... Only a fraction (I'm one of them) will use
debian for linux cross compiling. For Android cross compiling I believe that
almost nobody is using distribution Qt packages...

If you are using yocto, then you can build Qt in yocto as well. Which 
means yocto also creates the host Qt for you in the SDK with the correct 
pathes (according to their environment file).


___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] The sorry state of the Qt6 cross compile experience

[Tobias Hunger]

Hi BogDan,

On Tue, Feb 23, 2021, 12:30 BogDan Vatra via Development <
development@qt-project.org> wrote:

> - first and foremost, we need to waste time to **fully** build and install
> it
> for host platform (desktop). Yeah, I know that this was "decided" before
> TQC
> switched, overnight, to cmake, but let's face it, it's a BS needed to
> cover
> the fact that cmake can't build more than one platform at once.
>

We had the requirement to enable exactly that to stop wasting time in the
CI. This would have need to be met by any buildsystem used for Qt6.



No need to discuss implementation details ...

- IMHO the qmake build files were removed prematurely ... they should be
> removed **after** cmake matched qmake.
>

Making the old build system match the new one was never a goal.

Less maintenance effort was a goal, as was improving common use cases and
not making less important use cases impossible.

Having said that, I truly believe that cmake is a big step backwards.
> Am I the only one who's bother by all these things?
>

Some people always end up unhappy when you change things -- and when you do
not change things. Sorry that you ended up on the unhappy side!

We have a huge elephant in the room which nobody want to see it...
>

If that is your biggest concern about Qt right now: Lucky you.

Best Regards,
Tobias
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development