[Development] Stepping down as Android maintainer

[BogDan Vatra via Development]

Hello there,


  I have been less active on the Android port recently and Assam has been 
doing the majority of the work maintaining the Android port. 
I'm therefor stepping down as the maintainer of the Android port and 
nominate Assam to take over.


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

Re: [Development] How to make a qt6 module using cmake?

[Bogdan Vatra via Development]

Hi,
În ziua de marți, 21 noiembrie 2023, la 18:45:51 EET, Alexandru Croitor a 
scris:
> > On 21. Nov 2023, at 16:46, BogDan Vatra  wrote:
> > 
> > On 2023-11-21 16:47, Alexandru Croitor wrote:
> >>> On 21. Nov 2023, at 13:21, Bogdan Vatra via Development
> >>>  wrote: Hello there,
> >> 
> >> Hi,
> > 
> > Salut,
> > 
> > 
> > 
> > I tried qtmqtt to be sure that I didn't do any mistakes, it seems if I use
> > `qt-cmake` to configure the project it fails at `ninja docs` step, but if
> > I'm using `qt-configure-module`, as Kai recommended, it passed that step.
> The only relevant difference i can think of between qt-configure-module
> (which uses qt-cmake-private) and qt-cmake, is that the former will use the
> same cmake generator that was used to configure qtbase.
> 
> But if the configuration otherwise succeeded, and it's only docs target that
> failed, i'm not really sure what else could have gone wrong.

I found a way to reproduce it. Setting `CMAKE_INSTALL_PREFIX=/` or any path 
that is different from qt path breaks the docs compilation.

Cheers,
BogDan.

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

[Development] How to make a qt6 module using cmake?

[Bogdan Vatra via Development]

Hello there,

  I'm trying to port a qt5 module to qt6 which it seems starting with 6.4.x 
the qmake support is broke/removed for modules so I'm forced to use cmake...

I checked other qt modules (e.g. https://code.qt.io/cgit/qt/qtmqtt.git/tree) 
and I did mostly the same but there are a few problems:

 - They all use *internal* (version specific) stuff (e.g. 
qt_internal_project_setup, qt_internal_add_qml_module, etc.).
 - the `install` target doesn't install examples srcs.
 - how to add docs to examples? With qmake I needed only to have a `doc` 
folder in the example folder and it will parse all the .qdoc files for me.
 - the `docs` target doesn't seem to work:
```
qt.qdoc: Cannot find index directory:  "/home/bogdan/work/qt/qtmqtt/b/./doc"
/home/bogdan/work/qt/qtmqtt/src/mqtt/doc/qtmqtt.qdocconf:1: (qdoc) error: 
Cannot open file '//./doc/global/qt-module-defaults.qdocconf': No such file or 
directory
Cannot open file '//./doc/global/qt-module-defaults.qdocconf': No such file or 
directory
```

So, what's the recommended way to make a qt6 module using cmake?

Cheers,
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

[Bogdan Vatra via Development]

Hi,
În ziua de joi, 25 februarie 2021, la 12:40:30 EET, Dominik Holland a scris:
> Hi,
> 
> Am 2/25/21 um 11:07 AM schrieb Bogdan Vatra:
> > Hi,
> > 
> > În ziua de miercuri, 24 februarie 2021, la 17:32:57 EET, Dominik Holland a
> > 
> > scris:
> >> 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.
> > 
> > Vanilla yocto does NOT add Qt 5 for host, same for buildroot!
> > You probably mean that you're forcing yocto to add Qt 5 for host as well.
> > Joust out of pure curiosity, what's the reason to add Qt 5 for host in the
> > yocto SDK?
> 
> I'm not sure whether we are talking about the same thing here. But if
> you create a proper yocto SDK you want it to be usable standalone.
> Which means the host part of the yocto SDK contains the cross-compiler,
> gdb and other other host tools you need for the cross-compilation.
> This also includes the host-tools like qmake, moc, uic etc. as those are
> needed for cross-compiling to be executed on the host.
> 
> Yes, whether those host tools are part of the created SDK is on you to
> decide, but so far all yocto SDKs i have used so far ship the qt host
> tools in the SDK as well.
> 
> Yocto also uses the same host vs target build concept Qt6 is using now
> and for Qt5 yocto forced us to do the same thing as well, it's just
> behind the scenes:
> 
>  qtbase-native.bb: Native Qt build
>  qtbase(-target).bb: cross Qt build (using the moc, uic and friends from
> the native build)
>  qtbase-nativesdk.bb: Special nativesdk Qt build (Which provides the
> tools shiped with the SDK, this is not the same as the native build, as
> you could create a SDK for different target architecture e.g. mingw)
> 

I apologize, you're right. 

I only checked if buildroot's SDK if is working and it has only one Qt copy, 
which it has.
Indeed the yocto minimal sdk (qt5-image:populate_sdk) does not add Qt5 tools 
to host (for some reason it builds them for the target instead for the 
host...).

Sorry!

Cheers,
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

[Bogdan Vatra via Development]

În ziua de joi, 25 februarie 2021, la 12:07:17 EET, Mathias Hasselmann a 
scris:
> Am 23.02.2021 um 13:27 schrieb Marius Kittler:
> > The multi-ABI build never worked well for me with Qt 5. While it is
> > nice that
> > Qt's build system offers this feature it doesn't help with the fact that
> > other dependencies of my project don't support that. Hence it is still
> > easier to install each architecture within its own prefix which
> > unfortunately was broken by the multi-ABI build. Hence I don't miss that
> > feature at all.
> 
> Actually I use Android multi-ABI with CMake and it just works. With
> Android's stock toolchain file and hand written packing rules, as Qt
> just wasn't there when I switched to CMake. Well, and its Qt5... But why
> shouldn't work for CMake and Qt6, what's already working with Qt5?
> 

Because the support was *dropped* in Qt 6...

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

[Bogdan Vatra via Development]

Hi,

În ziua de joi, 25 februarie 2021, la 12:01:56 EET, Mathias Hasselmann a 
scris:
> Am 24.02.2021 um 09:30 schrieb Bogdan Vatra via Development
> 
> > Let's check some numbers: [...]
> > 
> > So, for 100M, you've added +700M.
> 
> Cost for storing one GiB of information on a SDD? Below 10 Cents.
> 
> What do you charge your customers for just one minute of watching your
> computer recompiling Qt?
> 
> What do you charge your customers for the endless time you spent in rage
> because change challenges you?
> 
> Pragmatism, Bogdan! Pragmatism!
> 

  Why do use Qt instead of HTML5? Today's embedded computers have enough CPU, 
RAM and storage to run super big and slow code as well ;-).

Cheers,
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

[Bogdan Vatra via Development]

Hi,

În ziua de miercuri, 24 februarie 2021, la 17:32:57 EET, Dominik Holland a 
scris:
> 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.
> 

Vanilla yocto does NOT add Qt 5 for host, same for buildroot!
You probably mean that you're forcing yocto to add Qt 5 for host as well. 
Joust out of pure curiosity, what's the reason to add Qt 5 for host in the 
yocto SDK?

Cheers,
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

[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

[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

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

[BogDan Vatra via Development]

Hi,

  Even though I said that I'm not opening this subject again, I must do it 
because in this moment, cross compiling Qt6 is painful and broken. 

  Long time ago, in the Qt 5 time, we had an painlessly way to do cross 
compiling, not only for Android, but also for the rest of the platforms.  Yes, 
I know, Qt 5 was using the evil, outdated qmake system which we all loved to 
hate, but it just worked for most of us.

Now cross compiling Qt6 for any platform is broken and painful:

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

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

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

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

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

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

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?

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

Yours,
BogDan.


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

[Development] How to build and install only host_tools ?

[Bogdan Vatra via Development]

Hi,

  I'm trying to build and install *only* host_tools and reuse them for all my 
cross platform compilation builds. I can build it with `ninja host_tools` but 
I could not found any `host_tools_install` or `install_host_tools` targets, 
and if I'm trying to install it with `ninja install` it will build and install 
everything not only host_tools. 

Am I missing something? Or there is no way to build and install only 
host_tools?

Cheers,
BogDan.


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

Re: [Development] [Qt-creator] Stepping down as maintainer of the CMake plugin of Qt Creator

[Bogdan Vatra via Development]

Hi,

  It is so sad to see you (and other great developers) leaving TQC ... Thank 
you so much for all the great work you did for QtCreator, and also for helping 
me with Android QtCreator plugin.

I wish you all the best with your new job!

Cheers,
BogDan.

P.S.  Regarding the CMake QtCreator plugin, it's fascinating to see how many 
people volunteered for this job. I bet that QtCreator's project manager will 
have so many problems coordinating all these people :).


În ziua de luni, 29 iunie 2020, la 17:24:22 EEST, Tobias Hunger a scris:
> Hello everyone!
> 
> I would like to step down as the CMake plugin maintainer in Qt Creator on
> 1st of August as I will start a new job then and do not expect to have the
> time necessary to be a good maintainer in the Qt project. Thank you all for
> the the opportunity to work with so many passionate people and the trust to
> maintain a plugin!
> 
> It would be great to see somebody step up to the task of making CMake easy
> and convenient to use in Qt Creator! I will be around and am willing to
> help getting people to settle into the code base -- as I still think this
> is a very important area for Qt Creator going forward.
> 
> The last couple of weeks I spend on streamlining the code (killing two of
> the three completely different ways for creator to interact with CMake) and
> to generally simplify the interaction between Qt Creator and CMake. I think
> this was a major step forward for CMake support in Creator  -- and it
> removed a lot of code and made things conceptually simpler, so now is a
> good time to hand over the plugin.
> 
> Best Regards,
> Tobias
> 
> PS: Please consider to test the upcoming Creator release and report issues
> you find so that I still have a chance to fix them myself:-)
> 
> --
> Tobias Hunger, Senior Software Engineer | The Qt Company
> The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
> Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho. Sitz der
> Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB
> 144331 B ___
> Qt-creator mailing list
> qt-crea...@qt-project.org
> https://lists.qt-project.org/listinfo/qt-creator



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

Re: [Development] Switch the main "Qt Build System"

[Bogdan Vatra via Development]

În ziua de marți, 9 iunie 2020, la 21:31:17 EEST, Thiago Macieira a scris:
> On Tuesday, 9 June 2020 01:26:12 PDT Alexandru Croitor wrote:
> > > On 9. Jun 2020, at 10:17, Jean-Michaël Celerier
> > >  wrote:
> > > 
> > > To simplify this step, is there / could there be maybe a
> > > -DQT_BUILD_TOOLS_ONLY that would just generate... well, moc, uic, rcc
> > > and
> > > a couple other friends required for a cross-build ?
> > 
> > I think that should technically be possible, but I have doubts about it.
> > 
> > Not all tools are "bootstrap" tools anymore, which means for uic you need
> > to build QtCore (same for qmake actually).
> 
> The whole point of not bootstrapping the tools for cross compilation is to
> remove as much as we can of the bootstrapping. Right now in 5.15, the only
> tools that really need bootstrapping are qmake and moc. And for 6.0 once the
> build system switch is merged, we can proceed to un-bootstrap qmake too and
> that removes one full level of bootstrapping.
> 
> That will leave us with only moc needing bootstrapping. We can therefore
> remove libQt5Bootstrap.a and minimise the amount of work needed to keep the
> bootstrap working.

  In this case why did you all had the super strict requirement list when we 
talked about using qbs as the build system for Qt 6? And why now you are so 
understanding and flexible with all the missing pieces from cmake?

  There are host tools that are not very forward or backward compatible (e.g. 
androiddeployqt) which might require a specific Qt version as it knows how to 
deal with a specific input files...

Cheers,
BogDan.

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

Re: [Development] Switch the main "Qt Build System"

[Bogdan Vatra via Development]

În ziua de marți, 9 iunie 2020, la 13:46:48 EEST, Edward Welbourne a scris:
> On 6/9/20 7:22 AM, Bogdan Vatra via Development wrote:
> >>> - if you'll not support/trash all .pro/.pri files how we'll push
> >>> fixes for 5.15 branch ? Because right now we can't push fixes
> >>> directly to 5.15.  branch and all the fixes must go trough dev
> >>> branch first.
> 
> În ziua de marți, 9 iunie 2020, la 10:35:33 EEST, Joerg Bornemann a scris:
> >> All changes that do not apply to Qt6 must go to 5.15.  It's not true
> >> that we can't push fixes to 5.15 anymore.
> 
> Bogdan Vatra (9 June 2020 12:12)
> 
> > If I have a fix which involves also changes to some .pr* files, where
> > it should go? In dev I can't push it because you nuked the .pr* files,
> > in 5.15 I'm banned.
> 
> This is by no means unique to .pr[fio] files: there's lots of code that
> we've deleted on dev, that shall need fixes on 5.15.  When a fix gets
> picked to 5.15, there is a risk that it'll apply and maybe even
> integrate; if so, a follow-up commit only on 5.15 can supply the parts
> of the change that aren't present on dev.  More usually, the pick will
> get conflicts or fail to integrate, so you'll get the chance to amend
> the picked commit on 5.15.  (Even in the first case, if you get the mail
> promptly, you can potentially unstage the pick before it gets integrated
> and fix it likewise.)
> 
> This applies to all the code that's being deleted on dev, including but
> by no means limited to qmake's configuration.
> 

But how can I send a fix to a .pr* file in dev if that file doesn't exists 
anymore in dev? In this case should we send the patches directly to 5.15. and 
add the "Cherry-pick: dev" thing to the patch message?

Cheers,
BogDan.

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

Re: [Development] Switch the main "Qt Build System"

[Bogdan Vatra via Development]

În ziua de marți, 9 iunie 2020, la 10:35:33 EEST, Joerg Bornemann a scris:
> On 6/9/20 7:22 AM, Bogdan Vatra via Development wrote:
> > - is it possible to cross compile Qt in one go (just like we do with
> > qmake)?
> Assuming you're talking about the multi-ABI Android build you've added
> to Qt5. This is not yet implemented, but certainly possible with the
> Ninja Multi-Config generator that has been added to CMake 3.17 [1].
> 
> > - if you'll not support/trash all .pro/.pri files how we'll push fixes for
> > 5.15 branch ? Because right now we can't push fixes directly to 5.15.
> > branch and all the fixes must go trough dev branch first.
> 
> All changes that do not apply to Qt6 must go to 5.15.
> It's not true that we can't push fixes to 5.15 anymore.
> 

If I have a fix which involves also changes to some .pr* files, where it should 
go? In dev I can't push it because you nuked the .pr* files, in 5.15 I'm 
banned.

IMHO we should keep qmake files in place until 6.0.0 it's out.

Cheers,
BogDan.

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

Re: [Development] Switch the main "Qt Build System"

[Bogdan Vatra via Development]

Hi,
În ziua de marți, 9 iunie 2020, la 11:13:21 EEST, Alexandru Croitor a scris:
> > On 9. Jun 2020, at 07:22, Bogdan Vatra  wrote:
> > 
> > - is it possible to cross compile Qt in one go (just like we do with
> > qmake)?
> Could you clarify what you mean by "in one go"?
> 
> If it's about building host tools as part of the cross-compilation, then no.
> You first have to build a desktop Qt, and re-use that host Qt installation
> for its tools, to cross-compile to another target.
> 
> That's been one of the goals for Qt 6 regardless of build system, and has
> been communicated a while ago.

When I'm cross-compiling Qt for a Linux device, Android, ios, etc., qmake it's 
smart enough to build everything for me: host tools and the libs for that 
target in one go i.e. I type ./configure .. && make and it does all the magic 
for me.

How qt modules that have host & target libs will be built with cmake?

I'm using qmake for Qt6 when I'm doing Android work, also for this reason.
I don't want to build Qt twice just to use a "cool and superior" build system.

Just out of curiosity, can some pretty please remind me what are the 
advantages of using cmake to build Qt over qmake?
I'm not talking about Qt users, for them we should support all (major) build 
systems: qmake, cmake, meson, etc.

Cheers,
BogDan.


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

Re: [Development] Switch the main "Qt Build System"

[Bogdan Vatra via Development]

Hi,

I have a few questions:
- is it possible to cross compile Qt in one go (just like we do with qmake)?
- if you'll not support/trash all .pro/.pri files how we'll push fixes for 5.15 
branch ? Because right now we can't push fixes directly to 5.15. branch and all 
the fixes must go trough dev branch first.

Cheers,
BogDan.

În ziua de luni, 8 iunie 2020, la 16:43:20 EEST, Alexandru Croitor a scris:
> Hi everyone,
> 
> It's time to talk about everyone's favourite topic again: build systems.
> 
> It's been a while since we started porting and merging the CMake ports of Qt
> repositories into the dev branches.
> 
> To be precise: qtbase got merged on the 7th of February.
> 
> Since then, all the enabled repositories in qt5.git/dev have CMake ports
> merged to their corresponding dev branches (except for qtqa which got
> reverted, but it should be back soon).
> 
> The CMake ports are built in Coin with the most important configurations
> (Linux, Windows, macOS, Android, iOS, qemu Linux).
> 
> Currently, failed tests don't fail integrations, but we're fixing up the
> last failing tests and intend to enforce successful test passing for CMake
> configurations.
> 
> Anyway, it's time for the next step.
> 
> 
> -> TL;DR here
> <
> 
> The CMake Port team wants to switch the main Qt build system to the CMake
> one.
> 
> What this means:
> 
> - All Coin qmake configurations in dev branch are removed.
> 
> - Only CMake configurations are built in Coin.
> 
> - CMakeLists.txt files are now the source of truth (no more editing of .pro
> / .pri files).
> 
> - All qmake .pro / .pri files of ported repositories under Coin control are
> removed.
> 
> - No more pro2cmake.py and configurejson2cmake.py usage (except for an
> initial port of a yet un-ported repository)
> 
> - You need CMake to build Qt.
> 
> - Un-ported repositories should still be able to build with qmake against a
> CMake built Qt (this was tested to work for qtwebengine, but not other
> repositories, there are a few known issues left that we're currently
> fixing).
> 
> 
> --> Proposed time of execution: 1st of July <--
> 
> 
> I'd like to hear about any Qt development blockers that you foresee due to
> this change.
> 
> 
> Regards,
> Alexandru.
> ___
> 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

Re: [Development] Make Qt6 JNI API safer to use

[Bogdan Vatra via Development]

Hi,

În ziua de joi, 5 martie 2020, la 17:14:44 EET, Vitaly Fanaskov a scris:
> I think something like std::expected is a nice thing to have.
> 
> There is some experimental implementation of std::expected: 
> https://github.com/TartanLlama/expected.
> 
That implementation is my favorite, I really like the map, map_error, 
and_then, or_else additions ;-) .

[...]
> 
> Regarding using exceptions, well, I would vote for this option, but I 
> don't think that this is possible at all to convince people to use 
> exceptions in this module.
> 
A single Qt JNI call might fail in different places, e.g.:
auto str1 = QAndroidJniObject::callStaticObjectMethod("MyClass",
"fromNumber",
   "(I)Ljava/lang/String;",
   10);

1. check if there is any pending exceptions on current JNI Env
2. check if the method signature is okay
3. check if the method call throw any exceptions

Using exceptions we can pinpoint what happened.

Imagine how hard will be without exceptions to pass as parameters more jni 
methods/fields results ...

Cheers,
BogDan.

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

Re: [Development] Make Qt6 JNI API safer to use

[Bogdan Vatra via Development]

În ziua de joi, 5 martie 2020, la 17:21:11 EET, Thiago Macieira a scris:
> On Thursday, 5 March 2020 07:14:44 PST Vitaly Fanaskov wrote:
> > I think something like std::expected is a nice thing to have.
> > 
> > There is some experimental implementation of std::expected:
> > https://github.com/TartanLlama/expected.
> > 
> > Another good example is Result
> > (https://doc.rust-lang.org/std/result/index.html) type from Rust. But
> > might look clumsy in C++, because there is neither pattern matching nor
> > operator?
> > (https://doc.rust-lang.org/std/result/index.html#the-question-mark-operato
> > r-> )  to handle this case gracefully.
> We have QSystemResult in QtCore already. This predates both std::expected
> and Result from Rust.
> 
> One of my abandoned commits (see the I/O thread) was an update to it to make
> it better.

Where is QSystemResult? I can't find it in dev branch ... Did you rename it?

Cheers,
BogDan.

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

[Development] Make Qt6 JNI API safer to use

[Bogdan Vatra via Development]

Hi,

  I started to review and move androidextras to qtbase (qtbase/src/corelib/
platform/android). Here we have a problem with our Qt JNI API. The problem is 
that in Java exceptions are (ab)used everywhere. Even if we have a way to 
check for exceptions after each call in Qt, it's not used (not even by us in 
Qt code itself), mostly because it's a little unwieldy to use it. To fix this 
issue I'd like to discuss with you a few options:

1 - add something similar to std::expected[0] or outcome[1] to Qt. We can't 
use std::optional because it doesn't work for void function e.g. 
std::optional callMethod(). std::expected allows our API users to 
handle the errors without try/catch. I think std::expected will be useful in 
many places not only for QtJNI e.g. QJsonDocument 
QJsonDocument::fromJson(const QByteArray , QJsonParseError *error = 
nullptr) or any other place where we pass the error result as an argument. 
Of course we still need to enable exceptions as if we try to access the 
returned value without checking its state first it will still throw an 
exception if the value is not valid.

2 - use exceptions (at least for android?). This means if a JNI call fails it 
will throw a C++ exception. IMHO this is by far the best, cleanest and easiest 
solution.

3 - I'm open for better ideas which makes the coding safer and *easier*.

Cheers,
BogDan.

[0] https://wg21.link/P0323R9 sadly it's not in c++20 :( therefore we need to 
either use an existing implementation or implement one in Qt.
[1] https://ned14.github.io/outcome/ 


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

Re: [Development] Changes to Qt offering

[Bogdan Vatra via Development]

În ziua de duminică, 2 februarie 2020, la 13:14:13 EET, Ville Voutilainen a 
scris:
> On Wed, 29 Jan 2020 at 18:11, Volker Hilsheimer  
wrote:
> > I wonder where all this love for the Qt installer comes from. I personally
> > consider “sudo apt-get install -y qtcreator” or “brew install qt-creator”
> > or “choco install qtcreator" to be vastly superior to using the installer
> > UI, and very easily integrated in VM provisioning. Any energy spent on
> > making sure that the versions we get from those package repos is
> > up-to-date would be worth a lot more (to me) than building another
> > installer.
> Qt installer resumes downloads after a network connection break.
> apt-get does not. :)

  You must be kidding, apt it's (one of) the best package manager! It resumes 
the download(s) from the same point from where the connection dropped.

Cheers,
BogDan.


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

Re: [Development] The future of smart pointers in Qt API

[Bogdan Vatra via Development]

Hi,

  It seem the community it's still pissed off on TQC, so I'm going to break the 
ice here :).
  I'll personally go with std::* (not only for smart ptrs but for everything 
else (e.g. containers), except QString of course). QPointer still needs to 
stay as there is nothing in std:: which we can use (unless it's not needed 
anymore).
  Regarding the second issue, I'd like to have (const) references & shared 
ptrs only and to avoid raw pointers. 

Cheers,
BogDan.

În ziua de vineri, 31 ianuarie 2020, la 12:07:52 EET, Vitaly Fanaskov a scris:
> Hello everyone,
> 
> We’ve been discussing for a while how Qt6 API can be improved with using 
> smart pointers. Recently we came into some conclusions and want to 
> discuss them with the community.
> 
> Smart pointers are for sure much better to use than raw pointers for 
> many reasons. They manage lifetime automatically, show ownership 
> semantic, and make code safer. It’s planned to officially recommend them 
> to use in Qt6 API instead of raw pointers whenever this is possible. For 
> sure, it should only be a choice for newly designed API.
> 
> But how to use them in the API and which way is preferable is still 
> unclear. There are two main options we have:
> 
> 1) Use std::*  smart pointers as-is.
> 
> 2) Add Qt-style wrappers around std::* smart pointers and move old 
> implementations of Qt smart pointers to the Qt5Compact module.
> 
> Both options have pros and cons. It would be useful to hear your 
> thoughts on it. It’s worth mentioning that some other options, like 
> using Qt smart pointers as-is, were also discussed. They were found less 
> suitable, but feel free to share your opinion if you disagree.
> 
> Another thing to discuss is whether we should use raw pointers in the 
> API at all or not. There are a few options again:
> 
> 1) Yes
> 
> 2) No. Use “modern” approaches instead (pass mandatory dependencies by 
> either reference or const reference when using smart pointers makes no 
> sense, use something optional-like or tuples to return extra data from 
> functions, and so on)
> 
> 3) Mix 1 and 2.
> 
> There are pros and cons for all options. Share your opinion once again, 
> please.
> 
> If there are any related things to discuss, let’s do that in this thread.
> 
> -- 
> Best Regards,
> 
> Fanaskov Vitaly
> Senior Software Engineer
> 
> The Qt Company / Qt Quick and Widgets Team
> 
> ___
> 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

Re: [Development] Changes to Qt offering

[Bogdan Vatra via Development]

În ziua de marți, 28 ianuarie 2020, la 15:26:34 EET, Lisandro Damián Nicanor 
Pérez Meyer a scris:
> Hi!
> 
> On 20/01/27 06:18, Thiago Macieira wrote:
> > On segunda-feira, 27 de janeiro de 2020 14:48:17 PST Alexander Akulich 
wrote:
> > > I would expect a significant negative effect on the quality of Qt
> > > shipped in Linux distributions and thus negative effect on the
> > > Qt-based applications and Qt reputation.
> > 
> > That is debatable since most Linux distributions do not align with the Qt
> > LTSes. Kevin's question of 5.15 support while 6.0 is coming is valid, but
> > for all other LTSes, open source Linux distros seem to choose whichever
> > version was latest at the time they reached feature-freeze.
> > 
> > Current versions in:
> > * Debian stable: 5.11.3
> > * Debian oldstable: 5.7.1
> > * Fedora 31: 5.12.5
> > * Fedora 30: 5.12.1
> > * Fedora 29: 5.11.1
> > * Fedora 28: 5.10.1
> > * CentOS 8.1: 5.11.1
> > * openSUSE 15: 5.9.4 (15.1 now has 5.9.7)
> > * openSUSE 42.3: 5.6.2
> > * openSUSE 42.2: 5.6.1
> > * (K)Ubuntu 19.10: 5.12.4
> > * Ubuntu 18.10: 5.11.1
> > * Ubuntu 18.04 LTS: 5.9.5
> > * Ubuntu 16.04 LTS: 5.5.1
> > * KDE Neon: 5.13.2
> > * Manjaro 18.1.0: 5.13.0
> > 
> > There are a couple of alignments with Qt LTS above but they could be
> > coincidences. openSUSE 15 was released around 6 months after the 5.10.0
> > release (and less than 3 after 5.10.1, which is when they seem to make
> > upgrades) and Ubuntu 18.04 was a month earlier than openSUSE. I thought
> > Fedora 31 was trying to align, but then I went to search for the current
> > version and F32-in-development has already upgraded out of the LTS to
> > 5.13.2.
> > 
> > Ubuntu snapshot for 20.04 is on 5.12.6. That seems to me to be the only
> > legitimate, intentional alignment on a Qt LTS. If that's confirmed, it
> > would be the first, after 4 years of having LTS releases.
> 
> I confirm that because one of their maintainers is also a team mate in
> Debian, read below.
> 
> > So it's completely understandable to have concluded that the LTS releases
> > weren't useful to Linux distributions.
> 
> With my Debian maintainer hat on: exactly as Thiago said. But with a note:
> we have always tried to ship a version as close to an LTS as we could (and
> I know the same goes for Ubuntu, as one of my team mates prepares Ubuntu's
> Qt packages from what we do in Debian). This is because it's normally
> easier to get the patches from a LTS. But the point remains the same.

  What happens when Qt 6 will be out and TQC closes 5.15 branch and you'll 
have to maintain Qt 5 for a couple of years without any bug fixes from 
upstream? As I pointed in my previous mails, the major risk here is that there 
will be a Qt 5.15 fork after the 5.15 branch is closed ... and nobody wins 
from such a scenario.

Cheers,
BogDan.


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

Re: [Development] Changes to Qt offering

[Bogdan Vatra via Development]

În ziua de marți, 28 ianuarie 2020, la 08:37:47 EET, Benjamin TERRIER a scris:
> Le mar. 28 janv. 2020 à 03:22, Thiago Macieira 
> 
> a écrit :
> > On segunda-feira, 27 de janeiro de 2020 14:47:46 PST NIkolai Marchenko
> > 
> > wrote:
> > > Assuming we have a VM that is restricted to connecting to the internet,
> > 
> > we
> > 
> > > previously could dump the installer there and install Qt.
> > > Now, we need to have an intermediary PC with the same OS to first
> > > install
> > > the binaries via online installer and then copy those binary files to
> > 
> > that
> > 
> > > first VM.
> > > 
> > > This is an extraneous and completely artificial step for absolutely no
> > > reason other than TQtC paywalling them, which is ridiculous.
> > 
> > Previously, you anonymously downloaded the offline installer from another
> > machine, then copied it over to the VM, and installed there.
> > 
> > Now you're going to download the offline installer from another machine
> > after
> > typing your password, then copy over to the VM and install there.
> > 
> > What's the hurdle?
> 
> You might have missed the info because it is in the blog post, but not in
> Lars email:
> 
> There will be no more open source offline installer.
> 
> For binaries, open source users will only have access to the online
> installer that will require a Qt Account.

  Folks, you have to understand that The Qt Company must pay its developers!
  I really don't bother if there will be offline installers only for commercial 
customers. Or if they will require an username to download from the 
online installer. Right now I'm not typing my user & pass just because the 
pass it's randomly generated and I'm too lazy to open my passwords app to get 
it.

  What I'm worried about is that there will be a 5.15 fork after TQC will 
close that branch. That fork will be necessary because you can't just switch 
projects like KDE from Qt 5 to Qt 6 overnight, it will take years to do it!
In all these years, all linux distributions that will ship Qt 5, will need 
regular updates with bug fixes, and because Qt 5.15 branch it's closed they 
will have to use either a "community" fork where all these distros will share 
their bugfixes or they will have their own patches. This means, it will be bad 
for TQC, because if these patches are not contributed via gerrit (CLA), TQC 
can't use them for commercial customers.

Cheers,
BogDan.


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

Re: [Development] Changes to Qt offering

[Bogdan Vatra via Development]

Hi Lars,

În ziua de luni, 27 ianuarie 2020, la 16:34:44 EET, Lars Knoll a scris:
> Hi all,
[...]
> 
> One is a change in policy regarding the LTS releases, where the LTS part of
> a release is in the future going to be restricted to commercial customers.
> All bug fixes will (as agreed on the Qt Contributor Summit) go into dev
> first. 

  I was at the Qt Contributor Summit, and I can swear that I not heard 
anything about LTS being restricted to commercial customers...

Just to be crystal clear, will you close also the branches?
What will happen if I want to fix something in one of these LTS branches?

> Backporting bug fixes is something that the Qt Company will take
> care of for these LTS branches. We’ve seen over the past that LTS support
> is something mainly required by large companies, and should hopefully help
> us get some more commercial support for developing Qt further.

I bet you the following scenario will happen soon:
- someone will fork Qt LTS (most probably immediately after you closed these 
branches, if not even sooner)
- the community will continue to support that fork as it's open, with 
improvements, bug fixes, security patches, etc.
- you'll not get these patches as they are not contributed via your gerrit...
 
 
> None of these changes should affect how Qt is being developed. There won’t
> be any changes to Open Governance or the open development model.
 
 If the qt5 branches will NOT be closed, then yes, you are right, if they will 
be closed then, I'm afraid, your statement can't stand...

Cheers,
BogDan.


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

Re: [Development] Nomination of Build System Maintainer(s)

[Bogdan Vatra via Development]

+1 for each :)

BogDan.

În ziua de miercuri, 15 ianuarie 2020, la 16:27:29 EET, Kai Köhne a scris:
> Hi,
> 
> I'd like to nominate Jörg Bornemann and Alexandru Croitor as joint official
> maintainers of the Build System in qtbase, which is officially unmaintained
> [1].
> 
> Jörg has been doing a lot of work and reviews in qmake and the existing Qt 5
> build system after Ossi was leaving The Qt Company.
> 
> Alexandru is currently organizing the work around the CMake port (Qt 6 build
> system), and also does a large fraction of the work himself.
> 
> I believe that, together, they are the right ones to maintain the build
> system area in both Qt 5 and Qt 6.
> 
> Their individual dashboards:
> 
> Jörg: https://codereview.qt-project.org/dashboard/1000120
> Alexandru: https://codereview.qt-project.org/dashboard/1004184
> 
> 
> Regards
> 
> Kai
> 
> [1] See https://wiki.qt.io/Maintainers
> 
> --
> Kai Köhne, Director R | The Qt Company
> 
> The Qt Company GmbH, Erich-Thilo-Straße 10, D-12489 Berlin
> Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho
> Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg,
> HRB 144331 B
> 
> ___
> 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

Re: [Development] Nominating Cristian Adam as approver

[BogDan Vatra via Development]

+1

Cheers,
BogDan.

În ziua de sâmbătă, 9 noiembrie 2019, la 21:07:42 EET, Tobias Hunger a scris:
> +1
> 
> Best Regards,
> Tobias



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

[Development] CI is quite unstable on windows

[Bogdan Vatra via Development]

Hi,

  I'm trying to integrate https://codereview.qt-project.org/c/qt/qtbase/+/
278646 but it always fails on windows in the very same place.
Can an windows expert to check these tests and if they can't be fixed/reliable, 
then blacklist them on windows?

Thanks.

Cheers,
BogDan.


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

Re: [Development] Gerrit update

[Bogdan Vatra via Development]

Hi,

  Since yesterday I can't submit any of my patches. The submit "button" is 
gay, e.g. https://codereview.qt-project.org/c/qt/qtbase/+/273675 

Am I doing something wrong?

Cheers,
BogDan.

În ziua de luni, 30 septembrie 2019, la 09:40:36 EEST, Heikki Halmet a scris:
> Hi,
> 
> Coin fixed and integrations should be work now. 
> Thanks for your patience!
> 
> 
> Br
> Heikki
> 
> -Original Message-
> From: Development  On Behalf Of Heikki
> Halmet
 Sent: maanantai 30. syyskuuta 2019 9.20
> To: Jukka Jokiniva ; Qt Project Development
> Mailing-List 
 Subject: Re: [Development]
> Gerrit update - problem with integrations 
> Hi,
> 
> We have problem in Coin with the newer Gerrit version. It means that
> currently integrations won't work. We are fixing the issue with highest
> priority.
 
> 
> Br
> Heikki
> 
> -Original Message-
> From: Development  On Behalf Of Jukka
> Jokiniva
 Sent: maanantai 30. syyskuuta 2019 8.52
> To: Qt Project Development Mailing-List 
> Subject: [Development] Gerrit is back online
> 
> 
> Gerrit is back online,
> 
> Main changes to the functionality are:
>* Confirmation dialog for Stage button has been removed.
>* Each staging attempt doesn't not generate new patch set for the change.
> New patch set is added only after successful integration.
 
>  --Jukka
> 
> 
> 
> On 30/09/2019, 7.57, "Development on behalf of Jukka Jokiniva"
> 
> wrote:
 
> 
> Hi,
> 
> Gerrit 3.0.2 upgrade starts in 5 minutes. The codereview.qt-project.org
> will be offline for about  20 - 30 mins.
 
> --Jukka
> 
> 
> 
> On 23/09/2019, 16.50, "Development on behalf of Frederik Gladhorn"
> 
> wrote:
 
> Hi all,
> 
> I hope this is a complete no-event, but we'd like to give you a
> heads-up, in 
 case something unexpected comes up. We Gerrit admins are
> currently working towards moving us to Gerrit 3.0.2.
> 
> The plan is to upgrade on Monday next week, the 30th of September.
> There are no huge improvements in Gerrit itself, it's a cleanup
> release 
 mostly, getting rid of the old database handling moving
> completely to note-db. 
> We don't expect major issues, the testserver upgrade takes around
> five minutes, 
 so there will be a short down-time, but otherwise there
> shouldn't be any real interruptions.
> We'll be testing in the meantime and may still postpone the upgrade,
> in case 
 any blockers are found.
> 
> Cheers,
> Frederik
> 
> 
> 
> ___
> 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
> 
> 
> ___
> 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
> ___
> 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

Re: [Development] Qt Contributors' Summit 2019 - Registration open!

[Bogdan Vatra via Development]

Hi,

  Considering that QtCS and QtWS are both in Berlin and both in Nov,  is there 
any reason why QtCS date was not choose immediately after QtWS (7-9)?

Cheers,
BogDan.

În ziua de miercuri, 18 septembrie 2019, la 17:42:18 EEST, Kai Köhne a scris:
> Hi,
> 
> Registration to the Qt Contributors Summit 2019 (Nov 19-21th) is now open!
> 
> https://www.surveymonkey.com/r/RNN7NXP
> 
> The event is open to anyone who has contributed to Qt. It is free of charge,
> but requires registration so that we can do some planning. There's also a
> maximum amount of people we can accommodate, so it's best to register as
> soon as you have made plans!
> 
> You can find more about the event at
> 
>   https://wiki.qt.io/Qt_Contributors_Summit_2019
> 
> We'll continue to update the wiki, especially the program page:
> https://wiki.qt.io/Qt_Contributors_Summit_2019_Program
> 
> Regards
> 
> Kai
> 
> --
> Kai Köhne, Director R | The Qt Company
> 
> The Qt Company GmbH, Erich-Thilo-Straße 10, D-12489 Berlin
> Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho
> Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg,
> HRB 144331 B
> 
> ___
> 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

Re: [Development] Proposal for an efficient and robust (de)serialization mechanism working with Qt-supported data

[Bogdan Vatra via Development]

Hi,

  It will be great if we can find a way to use it any (de)serialization 
mechanism (e.g. proto buff, flat buffers, etc.) not only with only one (qt 
specific).

Cheers,
BogDan.

În ziua de vineri, 30 august 2019, la 16:42:54 EEST, Simon Hausmann a scris:
> Hi Arnaud,
> 
> I think that perhaps this is also a topic worth discussing at the Qt
> Contributor Summit, if you can attend. During a face-to-face discussion we
> may be able to find a good understanding more efficiently of what exactly
> it is that we need in Qt.
> 
> I'm interesting in discussing how we can get away from QDataStream towards
> something more schema oriented. Perhaps that involves an intermediate
> abstraction similar to what you're proposal.
> 
> Simon
> 
> From: Development  on behalf of Arnaud
> Clere  Sent: Friday, August 30, 2019 15:37
> To: Edward Welbourne 
> Cc: development@qt-project.org 
> Subject: Re: [Development] Proposal for an efficient and robust
> (de)serialization mechanism working with Qt-supported data
> 
> Thank you,
> I will then submit a patch with the core of QBind and ask for reviewers.
> Arnaud
> 
> -Original Message-
> From: Edward Welbourne 
> Sent: jeudi 29 août 2019 17:39
> To: Arnaud Clere 
> Subject: Re: Proposal for an efficient and robust (de)serialization
> mechanism working with Qt-supported data
> 
> Hi Arnaud,
> 
> > I only received feedback from users in private, so I guess this is not
> > the right mailing list to ask for feedback on new features.
> 
> The development@ list is entirely apt as a place for this discussion.
> It's just that we're all rather busy (we just passed a feature freeze for a
> release we'll be polishing for the near future) and the Qt community
> generally works by "if no-one objects, go for it".  FWIW (not much, as this
> is outside my field of expertise) what you describe sounded interesting and
> worth turning into a code review on https://codereview.qt-project.org/
> 
> Eddy.
> ___
> 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

Re: [Development] HEADS-UP: Branching '5.14' from 'dev' complete, Qt 5.14 Feature Freeze in effect & '5.15' created

[Bogdan Vatra via Development]

Hi,

I can't edit https://wiki.qt.io/New_Features_in_Qt_5.14 ;-(.

Cheers,
BogDan.

În ziua de marți, 27 august 2019, la 10:00:46 EEST, Jani Heikkinen a scris:
> Hi all,
> 
> Final downmerge from dev to '5.14' is now done. All other modules are ready
> and merges in but qtbase merge
> (https://codereview.qt-project.org/c/qt/qtbase/+/271614) is still ongoing.
> So Qt 5.14 Feature Freeze is in effect now. Please fill Qt 5.14. new
> features in new features page (https://wiki.qt.io/New_Features_in_Qt_5.14)
> if not done yet.
> 
> Target is to get Qt 5.14 Alpha out as soon as possible. Let's see if that
> can happen already next week
> 
> As agreed earlier we have also created '5.15' for Qt 5.15.
> 
> So from now on
>- '5.14' is for Qt 5.14. No new features there anymore
>- '5.15' is for Qt 5.15 new features etc
>- 'dev' is for Qt6
> 
> And in addition there is also '5.12' and '5.13' branched open (+ of course
> 5.13.1 and 5.12.5 release branches) so merges will be quite hard. Merge
> path will be:
> 
> '5.12' -> '5.13' -> '5.14' -> '5.15' -> 'dev' (+ final merges from '5.13.1'
> -> '5.13' and '5.12.5' -> '5.12')
> 
> I bet that will be quite hard so I think we need to start dropping some
> merges quite soon...
> 
> br,
> Jani Heikkinen
> Release Manager
> 
> 
> From: Development  on behalf of Jani
> Heikkinen  Sent: Tuesday, August 20, 2019 8:44 AM
> To: development@qt-project.org; releas...@qt-project.org
> Subject: [Development] HEADS-UP: Branching from 'dev' to '5.14' started
> 
> Hi all,
> 
> '5.14' is soft branched from 'dev' now. Final downmerge from 'dev' to
> '5.14', Qt 5.14 Feature Freeze ( and most probably also branching '5.15'
> from '5.14' [1]) will happen Monday 26th August. So start using '5.14' for
> new changes targeted to Qt 5.14 release.
> 
> And please fill Qt 5.14. new features in new features page
> (https://wiki.qt.io/New_Features_in_Qt_5.14)
> 
> br,
> Jani Heikkinen
> Release Manager
> 
> [1]
> https://lists.qt-project.org/pipermail/development/2019-August/037109.html
> 
> 
> 
> 
> ___
> 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



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

Re: [Development] HEADS-UP: QStringLiteral

[Bogdan Vatra via Development]

Hi,

> Returning to your original post:
> >>> All the major frameworks out there (i.e. Java, C#) they have a
> >>> single String which does all the magic.
> 
> Yes, and those systems are all built with the assumption that client
> code doesn't care if every single time anything happens to a string a
> fresh copy of it is made.  They probably aren't actually that
> inefficient, but the basic premise of the design of those easy-to-use
> string classes is that if they were it wouldn't matter much.
> 

When I say framework, I actually mean the framework code not the client code. 
Let's take the java classes from Android, can you please show me a single 
place where Android folk are using some strange: String myString = 
StringLiteral("string") instead of a simple String myString = "string"; ?

> We don't have that luxury, sad to say,
> 

But we have the luxury to loose potential Qt contributors because we are going 
to force them to use so many string wrappers?

Cheers,
BogDan.


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

Re: [Development] HEADS-UP: QStringLiteral

[Bogdan Vatra via Development]

Hi,
În ziua de miercuri, 21 august 2019, la 13:53:02 EEST, Giuseppe D'Angelo via 
Development a scris:
> Hi,
> 
> On 21/08/2019 11:50, Bogdan Vatra via Development wrote:
> >Personally I'm not going to waste my time learning 10 sting wrappers
> >and
> > 
> > classes just to make some pico optimizations like:
> > 
> > QString ext = QLatin1String("exe"); // it's terribly wrong and people
> > which
> > are doing this mistake must be stoned to death!
> > 
> > QString ext = QStringLiteral("exe"); // it's so good and it will save the
> > planet from extinction!
> > 
> > // But
> > QString ext1 = QLatin1String("exe") + ext; // it's ok
> > // and
> > QString ext = QStringLiteral("exe") + ext; // it's a abomination!
> > 
> > // Even more
> > QHash test;
> > test[QLatin1String("key1")] = QLatin1String("some text %1").arg(1); //
> > wrong test[QStringLiteral("key1")] = QStringLiteral("some text
> > %1").arg(1); // wrong again
> > test[QLatin1String("key1")] = QStringLiteral("some text %1").arg(1); //
> > still wrong
> > test[QLatin1String("key1")] = QStringLiteral("some text %1").arg(1); //
> > victory !!!
> 
> How many of these are "mistakes" detectable by tooling? Because if they
> are, they're a very minor issue.
>

  Holy mother of sweet Jesus Christ, are you calling these "minor issues" ?!?! 
Are you insane ? :)

  I don't think there is any tooling smart enough to detect *ALL* the 
situations. In previous examples I used only QLatin1String and QStringLiteral 
let's not forget that there are many more: QString::fromX, QStringView, 
and probably more that I don't know about.
  THB I don't think tooling is the right answer here, I'm still dreaming to a 
single simple and nice string class and maybe *one* wrapper *if* is really 
needed.

Cheers,
BogDan.


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

Re: [Development] HEADS-UP: QStringLiteral

[Bogdan Vatra via Development]

Hi,

În ziua de miercuri, 21 august 2019, la 00:12:59 EEST, Thiago Macieira a 
scris:
> On Tuesday, 20 August 2019 08:56:06 PDT Bogdan Vatra via Development wrote:
> >   Isn't silly to have so many wrappers around a such a simple thing as
> > 
> > strings?
> 
> We all wish it were simple. If it were, we would have no need for so many
> string classes, for Marc's email and even for SG16 (Unicode) to exist in the
> C++ committee.

You didn't answered my questions :).
  The most important one is: can we have  *A single* String class and *A* 
single sting wrapper for each UTF-X variant?

  Personally I'm not going to waste my time learning 10 sting wrappers and 
classes just to make some pico optimizations like:

QString ext = QLatin1String("exe"); // it's terribly wrong and people which 
are doing this mistake must be stoned to death!

QString ext = QStringLiteral("exe"); // it's so good and it will save the 
planet from extinction!

// But
QString ext1 = QLatin1String("exe") + ext; // it's ok
// and 
QString ext = QStringLiteral("exe") + ext; // it's a abomination!

// Even more
QHash test;
test[QLatin1String("key1")] = QLatin1String("some text %1").arg(1); // wrong
test[QStringLiteral("key1")] = QStringLiteral("some text %1").arg(1); // wrong 
again
test[QLatin1String("key1")] = QStringLiteral("some text %1").arg(1); // still 
wrong
test[QLatin1String("key1")] = QStringLiteral("some text %1").arg(1); // 
victory !!!

Am I the only one which finds situations silly ? Of course there are more 
examples with the other String wrappers/functions in Qt, but I think is enough 
to show how crazy is the situation.

Cheers,
BogDan.


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

Re: [Development] HEADS-UP: QStringLiteral

[Bogdan Vatra via Development]

Hi,

  Isn't silly to have so many wrappers around a such a simple thing as 
strings? All the major frameworks out there (i.e. Java, C#) they have a single 
String which does all the magic.

  In Qt we have: QString, lost of QString::fromXXX, QLatin1String, 
QStringLiteral, QStringView, QByteArray (which si a castrated version of 
QString for some kind of utf-8 strings) and of course a few QByteArray::from. 
You might think using QString{u"myString"} will save you from all these 
madness and to save a few CPU ticks, well, you have tot think again, 
QString{u"myString"} isn't working!
  Is it that hard to have *A* single String for UTF-16 and *A* single one for 
UTF-8? Ot at least A single String class and *A* single sting wrapper for each 
UTF?

Cheers,
BogDan.



În ziua de marți, 20 august 2019, la 13:04:12 EEST, Mutz, Marc via Development 
a scris:
> Hi,
> 
> In light of a recent attempt to re-introduce QStringLiteral, relacing
> QLatin1String, I'd like to remind everyone that QStringLiteral has a lot
> of drawbacks and should not be used unless it saves a memory allocation.
> 
> Drawbacks include:
> 
> - doubled storage requirements (2 bytes/char) over a L1/US-ASCII string
> - unsharability with C strings (each QStringLiteral contains a new
> lambda, lambdas have unique types, static data in token-for-token
> identical lambdas is duplicated, merging these violates the standard)
> - introduction of QString dtor calls (cannot be optimized away)
> 
> Anti-patterns include: Using QStringLiteral in
> 
> - comparisons (includes relational operators, indexOf, contains)
> - composition (QStringBuilder, append, prepend, arg() (now partly
> available on QStringView and QLatin1String, too)
> - lookup and, I believe, even insertion, in JSON and soon CBOR classes
> - debug statements (we prefer debug code to be compact, not fast)
> - arguments to any other function overloaded QStringView or
> QLatin1String
> 
> Alternatives to QStringLiteral:
> 
> - u"..." (→ QStringView)
> - QLatin1String
> 
> Please take note of the following recent developments:
> 
> - arg(string, , string) ("multiArg") is available now on QL1S and
> QStringView
>- number formatting isn't, yet
> - You can use u"..." in Qt sources unconditionally
>- converts implicitly to QStringView
> - To convert QString → QStringView, prefer qToStringViewIgnoringNull()
> when you don't need to distinguish between the null and the empty state.
> It saves a branch.
> 
> Please help spreading this knowledge in review and your own work.
> 
> Thanks,
> Marc
> 
> ___
> 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

Re: [Development] Supported compilers for Qt 6

[BogDan Vatra via Development]

On 2019-08-12 22:34, Thiago Macieira wrote:

On Monday, 12 August 2019 08:11:38 PDT Thiago Macieira wrote:

distributions and Android SDKs use.


Any word on what Clang the Android SDK we'll require uses?


  NDK r19 and NDK r20 are shipped with clang 8.0, which according to 
https://clang.llvm.org/cxx_status.html hs proper c++17 support.
According to 
https://android.googlesource.com/platform/ndk/+/master/docs/Roadmap.md 
even modules will be supported soon. Anyway will not be an issue, 
because usually, the users are using the latest NDKs which have modern 
compilers.


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

[Development] Is CI broken ?

[Bogdan Vatra via Development]

Hi,

  I'm trying to stage a patch( https://codereview.qt-project.org/c/qt/qtbase/
+/266489 ), but I'm getting the same error each time. Is anyone working on it?

Cheers,
BogDan.


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

Re: [Development] Proposing CMake as build tool for Qt 6

[Bogdan Vatra via Development]

[...]
> > 
> > [...]
> > 
> > Are you seriously thinking that Qt is going to use scripts from some
> > random
> > github projects ?!?!?
> 
> There is a choice: with cmake you either spend hours yourself developing
> stuff, or reuse results of those who went through that hell before you :)

Or use a buildsystem that doesn't take to the hell?

> >>  > android and whatever next os is coming.
> >> 
> >>  Oh come on (bis). CMake has been one of the official android build
> >> systems
> >>  for close to two years now :
> >> https://developer.android.com/ndk/guides/cmake> 
> > Your statement is misleading! Can you use the "official" cmake to build an
> > Android *PACKAGE*? (e.g. build the c/c++ bits for all android ABIs in one
> > go, build the java, aidl, etc files, add resources and finally create &
> > sign your APK? CMake is spawned by gradle (for each ABI) and is used
> > *ONLY* to build the C++ files because people refused to port their cmake
> > projects to gradle. This means that gradle is the *official* build system
> > not cmake!
> > You either don't know how an Android package is built or if you know then
> > you're intentionally lie people...
> > 
> > Same for iOS, Fuchsia and other OSs that you enumerate: Can you use cmake
> > to build a *PACKAGE*?
> 
> There is CPack thing that can build packages. No idea if it supports Android
> in particular.

  If you don't know if it supports Android (or iOS, Fuchsia, etc), why did you 
bother to mentioned it?
  With so much support our there you should find if CPack can do all the steps 
to build an Android package in seconds, right?

Cheers,
BogDan.


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

Re: [Development] Proposing CMake as build tool for Qt 6

[Bogdan Vatra via Development]

Hi,

> 
> Though I can't help but wonder what is the magical ingredient in build
> systems that has the power to generate such vigorous debates over the
> internet.
> 

  Because the buildsystem makes the difference between wasting so many hours on 
writing build system scripts or using that time to improve your application,  
to think to better algorithms, do something useful.

BogDan.


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

Re: [Development] Proposing CMake as build tool for Qt 6

[Bogdan Vatra via Development]

Hi,

[...]
> 
> > qnx
> 
> you mean like software companies using Qt do, today ?
> https://github.com/mapbox/mapbox-gl-native/blob/master/platform/qt/qnx.cmake
> > vxworx
> 
> VxWorks ships with CMake so there must be at least some amount of support. (
> https://tp.prosoft.ru/docs/shared/webdav_bizproc_history_get/234075/234075/
> ?ncc=1_download=1 )
> 
[...]

Are you seriously thinking that Qt is going to use scripts from some random 
github projects ?!?!?

> 
> > android and whatever next os is coming.
> 
> Oh come on (bis). CMake has been one of the official android build systems
> for close to two years now : https://developer.android.com/ndk/guides/cmake
> 

Your statement is misleading! Can you use the "official" cmake to build an 
Android *PACKAGE*? (e.g. build the c/c++ bits for all android ABIs in one go, 
build the java, aidl, etc files, add resources and finally create & sign your 
APK? CMake is spawned by gradle (for each ABI) and is used *ONLY* to build the 
C++ files because people refused to port their cmake projects to gradle. This 
means that gradle is the *official* build system not cmake!
You either don't know how an Android package is built or if you know then 
you're intentionally lie people...

Same for iOS, Fuchsia and other OSs that you enumerate: Can you use cmake to 
build a *PACKAGE*?

Cheers,
BogDan.


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

[Development] Proposing a wiki page for Qt6 buildsystem requirements

[Bogdan Vatra via Development]

Hi,

  I'd like to propose a new wiki page (https://wiki.qt.io/Qt6/Requirements ?) 
where, at least all platform maintainers, will add all the features they need 
for that platform.
  As the Android maintainer I'm not happy with current qmake support, not to 
mention cmake support which in this moment is behind qmake.

Cheers,
BogDan.

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

Re: [Development] Proposing CMake as build tool for Qt 6

[Bogdan Vatra via Development]

În ziua de sâmbătă, 15 iunie 2019, la 19:32:52 EEST, Thiago Macieira a scris:
> On Friday, 14 June 2019 23:45:47 PDT Bogdan Vatra via Development wrote:
[...]
> 
> > So, as long as we need to provide libs, (qml) plugins  for debug & release
> > I think building them in one go is a must have feature.
> 
> Why must they be built in one go? Why can't they be separate builds stitched
> together? Or even completely separate builds as on Linux and all the other
> Unix?
> 

  Because qmake can build them in one go and last but not least is very 
convenient. Because a "new" buildsystem should do more than the existing one, 
not less :).

[...]
> 
> >   Just to be clear, I don't want to change TQC mind again, but I don't
> >   like
> > 
> > people hiding or twisting the true. The true is that in this moment CMake
> > is not the best option but, arguably, the worst one. It has the least
> > features and it has the ugliest syntax than the alternatives qmake and
> > QBS.
> But it has the most support base and the most experience out there, which
> was ostensibly the reason I posted. If users and packagers have problems,
> the pool of people who can help is much bigger.

  IMHO "the most support base and the most experience out there" it's just an 
appearance, or at least all these "support" and "experience" doesn't apply to 
Qt, I'll reiterate a few examples : 
 - no PCH (in decades)
 - no iOS (it seems we need to wait for 3.15 to have *some* support, let's not 
forget that iOS it's over a decade old)
 - no multi ABIs builds in one go (needed for msvc and useful also for 
Android). 
  My *hunch* is that 3.15 won't be enough to build all Qt platforms and we'll 
probably needs to wait a little bit more. IMHO cmake superiority it's just a 
myth, because, obviously, in *this moment* qmake is a superior buildsystem 
*for Qt*.
  Again, I want to highlight the fact that I don't want to change TQC decision 
regarding Qt6 and CMake, my comments are only for the sake of the truth.

BogDan.


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

Re: [Development] Proposing CMake as build tool for Qt 6

[Bogdan Vatra via Development]

Hi,

În ziua de joi, 13 iunie 2019, la 18:22:14 EEST, Thiago Macieira a scris:
> On Thursday, 13 June 2019 01:06:06 PDT Bogdan Vatra via Development wrote:
> > Hi,
> > 
> >   There is one more missing feature to add to your list: build & debug
> > 
> > builds for msvc in one go (same as qmake does now, a single "make" command
> > will build both targets).
> 
> I wouldn't call that a hard requirement. Separate builds for debug and for
> release are acceptable, the same way that we've ostensibly had support for
> shared-and-release builds but in practice they're always built separately.
> 
> The only difficult part I see is enforcing the suffix. On Mac we've had
> problems with this, since a debug-only build is un-suffixed. Maybe it's time
> to rethink the strategy and make the suffix optional altogether (using the
> lib infix feature). On Windows, we should stop enforcing that unoptimised
> builds be -MDd and make it easy for people to debug into -MD libraries.
> Hardly anyone ever debugs into Microsoft's libraries...
> 

I think libs built with -MDd are a must to enable debug builds for your 
application. AFAIK (if I'm wrong I apologize) you can't mix debug apps with 
release libs.
So, as long as we need to provide libs, (qml) plugins  for debug & release I 
think building them in one go is a must have feature.

> >   Also I wonder when do you plan to release Qt6? Because according to
> > 
> > Thiago's "what a buildsystem must to have list" he mentioned that the
> > buildsystem should be at least 2 years in the wild. If the needed cmake
> > support is not implemented yet, are you going to delay Qt 6 release (I
> > won't mid to use C++20 in Qt 6 :) ) just to give time to cmake to mature?
> > Or that (part of the) list was just an excuse for TQC to ditch QBS ;-).
> 
> 2 years in the wild was not for all features, it was for the buildsystem
> itself and the major features. But we need to build with the version that
> comes with the host systems that we are targetting (if they ship tools like
> this in the first place; Windows doesn't).
> 
> That means that the iOS support only needs to be present in whatever version
> of CMake that Homebrew installs. Since Homebrew always has the latest, this
> is not an impediment.
> 
> But if we want to build on Ubuntu 16.04, then that three year old version's
> CMake needs to be sufficient for a native build of Qt and whatever cross-
> builds get targeted from Linux (Android and QNX, I'd guess). For Qt 6, I'd
> just recommend raising the minimum to 18.04...

  What makes you think that you can build Qt for any platform with cmake found 
in Ubuntu 16.04 (or any later version) ?
  According to https://code.qt.io/cgit/qt/qtbase.git/tree/CMakeLists.txt?
h=wip/cmake#n1 Qt needs CMake *3.15.0* which is not even released. This means 
you'll need *NEXT* Ubuntu LTS (20.04?) to build Qt, this means we should put 
Qt6 on pause until 2022 :).

  Just to be clear, I don't want to change TQC mind again, but I don't like 
people hiding or twisting the true. The true is that in this moment CMake is 
not the best option but, arguably, the worst one. It has the least features 
and it has the ugliest syntax than the alternatives qmake and QBS.

Cheers,
BogDan.


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

Re: [Development] Proposing CMake as build tool for Qt 6

[Bogdan Vatra via Development]

Hi,

  There is one more missing feature to add to your list: build & debug builds 
for msvc in one go (same as qmake does now, a single "make" command will build 
both targets).

  Also I wonder when do you plan to release Qt6? Because according to Thiago's 
"what a buildsystem must to have list" he mentioned that the buildsystem 
should be at least 2 years in the wild. If the needed cmake support is not 
implemented yet, are you going to delay Qt 6 release (I won't mid to use C++20 
in Qt 6 :) ) just to give time to cmake to mature? Or that (part of the) list 
was just an excuse for TQC to ditch QBS ;-).

QBS Android (and iOS) support is far superior to both cmake & qmake. It's not 
only compiles your bins (for all ABIs at once!) but it also compiles the java, 
aild, etc. parts and it packages them using the android tools directly, which 
gives it a faster build time than any other build system out there, yes faster 
than qmake/cmake + gradle!

I just hope that even if you'll use cmake to build qt itself, we can still be 
able to use any buildsystem to build our Qt Apps. 

Cheers,
BogDan.


În ziua de joi, 13 iunie 2019, la 10:42:33 EEST, Lars Knoll a scris:
> Hi all,
> 
> After all the discussion, lets go back to the original proposal. We can see
> from the discussions that there is still work to be done, but I can’t find
> anything that sounds like a real showstopper.
 
> The two missing features that were voiced as a concern (if I didn’t miss
> anything in the thread) where multi arch/fat binary support for iOS and PCH
> support. I also heard that the people working on it are confident they can
> get this fixed in time for Qt 6, something I’m happy with for now.
> Nevertheless, I think it would be good if the team working on the cmake
> port could summarise how/when they are planning to fix this.
 
> One additional concern was multi arch builds for Android, but I don’t think
> that counts as a concern as qmake does not support this neither (so it
> would be a new feature).
 
> Finally, there was a concern around qmake support for users of Qt. This is
> something I have discussed with the team in the past, and it is a strong
> requirement that qmake will continue working as a build system for our
> users at least for the foreseeable future. This can and will be solved by
> cmake creating the required files to support qmake. Btw, this is also a
> hard requirement to be able to change build system repository by
> repository, so that we don’t have to do a all or nothing switch of all our
> repos.
 
> In summary, I do agree with and support the initial proposal by Simon to
> merge wip/cmake into wip/qt6.
 
> Cheers,
> Lars
> 
> 
> > On 6 Jun 2019, at 14:43, Sérgio Martins  wrote:
> > 
> > On Thu, Jun 6, 2019 at 12:45 PM Simon Hausmann 
> > wrote:
> 
> >> 
> >> Hi,
> >> 
> >> In the past months we, some developers from the Qt Company and KDAB,
> >> have made good progress on the port of Qt to use CMake as build tool.
> > 
> > 
> > +1, simply because we only have 1 contender so far.
> > 
> > Thanks for stepping up and doing the work.
> > 
> > Regards,
> > Sérgio Martins
> > ___
> > 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



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

Re: [Development] Proposing CMake as build tool for Qt 6

[Bogdan Vatra via Development]

Hi,

  Multi-arch builds was the biggest win of QBS which supported them not only 
for iOS but for Android and I think for any platform.
  Again multi-arch builds are out for years but no cmake support :).

Cheers,
BogDan.

În ziua de joi, 6 iunie 2019, la 16:28:20 EEST, Alexandru Croitor a scris:
> Hi,
> 
> There are 3rd party solutions for PCH in CMake, but we have not tested those
> yet.
 
> 
> Regarding iOS, I did some investigation work 2-ish months ago and here's
> what I can say:
 
> - CMake still has bugs here and there regarding iOS, but the patches I
> submitted so far to upstream CMake were merged. So I hope along the way we
> can iron out the issues before Qt 6 is released.
 
> - CMake has no proper support for doing multi-arch builds (simulator x64 +
> arm64 at the same time). We would either have to find a way to fix it
> upstream, possibly find some hack, or resort to building multiple types for
> different architectures, and then lipo-ing things together. 
 
> Note that the current support for multi-arch builds in qmake I would call
> hack-ish, given that no other build tool that I know of, does the same
> things that qmake does.
 
> - We will have to figure out which 3rd party package provide we want to use
> for CI, for packages like PCRE2, Freetype, etc, because for all the ones i
> tried (Conan, vcpkg, hunter), all of them need custom patches to support
> iOS builds.
 
> Other than that, with some WIP non-merged patches in qtbase, I was able to
> build parts of qtbase with CMake, targeting armv8 iOS.
 
> So there's still some work to be done, but in principle it should be
> doable.
 
> 
> > On 6. Jun 2019, at 15:13, Bogdan Vatra via Development
> >  wrote:
 
> > În ziua de joi, 6 iunie 2019, la 14:45:14 EEST, Simon Hausmann a scris:
> > 
> >> Hi,
> >> 
> >> In the past months we, some developers from the Qt Company and KDAB,
> >> have made good progress on the port of Qt to use CMake as build tool.
> >> Since the initial prototype, the port has advanced very well and its
> >> current state can be summarized roughly like this:
> >> 
> >> 
> >>* Builds on
> >>
> >>  * Windows (desktop)
> >>  * macOS
> >>  * Linux (desktop and embedded)
> >>  * Android (running not tested yet)
> >> 
> >> 
> > 
> > 
> > Any news about iOS/tvOS/watchOS and PCH?
> > 
> > Cheers,
> > BogDan.
> > 
> > 
> > ___
> > 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

Re: [Development] Proposing CMake as build tool for Qt 6

[Bogdan Vatra via Development]

Hi,

I won't hold my breath for community support for iOS. iOS is out for so many 
years, yet CMake has no support for t.

iOs is not a show stopper if and only you're prepared to drop this plaform 
from Qt 6 in case cmake support will be poor or non existing.

Cheers,
BogDan.


În ziua de joi, 6 iunie 2019, la 16:23:21 EEST, Simon Hausmann a scris:
> Hi,
> 
> Regarding PCH, it seems that right now it would be easiest to include
> something like https://github.com/sakra/cotire . Patches are welcome to
> integrate this or alternatively work with upstream CMake for a built-in
> solution.
> 
> Regarding iOS/tvOS/watchOS, my understanding is that CMake upstream has
> landed basic support from a toolchain perspective and welcomes
> contributions to make it better. I understand that Alexandru has been
> playing with making a Qt build with it and supplying third-party libraries
> via vcpkg, but I think that's nothing beyond the scope of experiments. So
> similarly here, contributions are welcome :)
> 
> Those two aspects are also a driver for increasing the visiblity of the
> CMake port, in order to invite contributors to help. Yet I feel that they
> don't represent show-stoppers from a decision making point of view. I'm
> confident that if others in the C++ community are able to build apps for
> iOS with CMake, then we will also be able to build Qt for it.
> 
> Simon
> 
> 
> From: Bogdan Vatra 
> Sent: Thursday, June 6, 2019 15:13
> To: development@qt-project.org
> Cc: Simon Hausmann
> Subject: Re: [Development] Proposing CMake as build tool for Qt 6
> 
> În ziua de joi, 6 iunie 2019, la 14:45:14 EEST, Simon Hausmann a scris:
> > Hi,
> > 
> > In the past months we, some developers from the Qt Company and KDAB,
> > have made good progress on the port of Qt to use CMake as build tool.
> > Since the initial prototype, the port has advanced very well and its
> > 
> > current state can be summarized roughly like this:
> > * Builds on
> > 
> >   * Windows (desktop)
> >   * macOS
> >   * Linux (desktop and embedded)
> >   * Android (running not tested yet)
> 
> Any news about iOS/tvOS/watchOS and PCH?
> 
> Cheers,
> BogDan.



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

Re: [Development] Proposing CMake as build tool for Qt 6

[Bogdan Vatra via Development]

În ziua de joi, 6 iunie 2019, la 14:45:14 EEST, Simon Hausmann a scris:
> Hi,
> 
> In the past months we, some developers from the Qt Company and KDAB,
> have made good progress on the port of Qt to use CMake as build tool.
> Since the initial prototype, the port has advanced very well and its
> current state can be summarized roughly like this:
> 
> * Builds on
>   * Windows (desktop)
>   * macOS
>   * Linux (desktop and embedded)
>   * Android (running not tested yet)
> 

Any news about iOS/tvOS/watchOS and PCH?

Cheers,
BogDan.


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

Re: [Development] Qt 5 types under consideration for deprecation / removal in Qt 6

[Bogdan Vatra via Development]

În ziua de vineri, 31 mai 2019, la 19:03:46 EEST, Thiago Macieira a scris:
> On Thursday, 30 May 2019 22:45:02 PDT Bogdan Vatra via Development wrote:
> > Hi,
> > 
> > În ziua de vineri, 31 mai 2019, la 08:36:31 EEST, Thiago Macieira a scris:
> > > On Thursday, 30 May 2019 15:51:26 PDT Konstantin Tokarev wrote:
> > > > BTW, are you also planning to drop support for using PCH with GCC-like
> > > > compilers when building Qt? It's a thing that is trivial to do with
> > > > make
> > > > or
> > > > qmake, but turns into rocket science with cmake.
> > > 
> > > PCH becomes "not our problem" if we switch to CMake. Please talk to
> > > CMake
> > > devs to make the feature possible.
> > 
> > PCH becomes *our problem* if we switch to CMake, same for iOS support!
> 
> PCH is a nice to have, but does not stop us from building Qt.
> 
> iOS support is a problem. We need to make sure the tools we choose support
> us.

Without PCH the build time will increase a lot.


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

Re: [Development] Qt 5 types under consideration for deprecation / removal in Qt 6

[Bogdan Vatra via Development]

Hi,

În ziua de vineri, 31 mai 2019, la 08:36:31 EEST, Thiago Macieira a scris:
> On Thursday, 30 May 2019 15:51:26 PDT Konstantin Tokarev wrote:
> > BTW, are you also planning to drop support for using PCH with GCC-like
> > compilers when building Qt? It's a thing that is trivial to do with make
> > or
> > qmake, but turns into rocket science with cmake.
> 
> PCH becomes "not our problem" if we switch to CMake. Please talk to CMake
> devs to make the feature possible.

PCH becomes *our problem* if we switch to CMake, same for iOS support!

Cheers,
BogDan.


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

Re: [Development] Qt online SDK security problems

[Bogdan Vatra via Development]

În ziua de joi, 18 aprilie 2019, la 13:54:15 EEST, André Pönitz a scris:
> On Thu, Apr 18, 2019 at 10:24:24AM +0300, BogDan Vatra via Development
> 
> wrote:
> > Hi,
> > 
> >   Long time ago the Qt online SDK used to help the users to use the
> >   latest and the safest Qt version all the time.
> 
> There is no latest *and* safest version of any non-trivial code base
> that's under active feature development no matter what Google,
> Microsoft, Apple, ("long time ago" Nokia) say.
> 
> The approach to always update is popular because it's an easy way to
> bundle items/features/changes/services that users otherwise might not
> agree with, with "security" fixes that people have been trained to
> accept.
> 
> When you mix feature development and security fixes you trade some known
> problems which you can evaluate whether they affect or to not affect
> your particular use case for a bag of unknown new problems which you
> cannot evaluate since you do not know them.
> 
> That's security by obscurity at best.

IMHO you approach is pretty wrong. 
First and foremost, the patch releases usually do not contain any new 
features. They are containing only bug and security fixes.
Why should we spend (waste?) time to fix bugs and security issues and to 
package new Qt patch versions if these versions are so evil and nobody wants 
to use them?

Even I'm repeating myself the third time in this thread, I'll do it one more 
time, maybe now it's more clear:
I'm not asking to have **only** the latest Qt version as it was long time ago. 
I'm asking to have a choice, if I want to use the latest version, the Qt 
online installer should help me. If I want to install a specific version, fine, 
I'll install that version and the installer will not update it anymore.

Cheers,
BogDan.

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

Re: [Development] Qt online SDK security problems

[Bogdan Vatra via Development]

Hi,

 As I said, they still have the possibility to install a specific Qt version 
and stick with it. The installer will not force them to use the latest 
version! If some companies prefer to use outdated software which might have 
security issues is their choice, what I'm asking is for an easy way for the 
other companies/people to use the latest Qt versions.
  One of the biggest problems when installing multiple Qt versions is that you 
end-up with multiple Kits in QtCreator. Small projects can switch from one kit 
to another very easy, but complex projects which need lots of custom qmake 
params or custom Build/Run steps are not that easy to swicth to another Qt 
version.
  Last but not least, it's a waste of disk space. Just ~/Qt/5.12.2 
(android_arm64_v8a+android_armv7+gcc_64) installation has 1.7GB.

Cheers,
BogDan.

În ziua de joi, 18 aprilie 2019, la 11:18:30 EEST, Maurice Kalinowski a scris:
> Hey,
> 
> Disclaimer: I am not involved in the decision making process for this
> update.
 
> However, one frequent feedback has been, that users (customers) did not like
> the fact that the installer changed the specific Qt version "under the
> hood".
 It was specifically requested that each user has to select the
> version to use. This is related to the fact, that many companies decide on
> one version and updating to a new one involves quite a lot of QA and other
> processes. Only then, developers are allowed to switch to a newer version. 
> This is (IIRC) why the installer switched to this approach.
> 
> I can see your point as well, especially when your project is flexible
> enough to update dependencies. But that is not the case for many projects
> out there.
 
> BR,
> Maurice
> 
> 
> 
> > -----Original Message-
> > From: Development  On Behalf Of
> > BogDan Vatra via Development
> > Sent: Thursday, April 18, 2019 9:24 AM
> > To: development@qt-project.org
> > Subject: [Development] Qt online SDK security problems
> > 
> > Hi,
> > 
> > 
> >   Long time ago the Qt online SDK used to help the users to use the latest
> >   and
> 
> > the safest Qt version all the time. Sadly that was changed, IMHO without
> > too
 much thinking, and now a lot of users (I'm one of them) are stucked
> > with outdated versions. A few days ago I installed 5.12.2 and today
> > suprise is outdated again.  It’s just ridiculously, I have five 5.9.x,
> > 5.10.0, two 5.11.x and three 5.12.x versions, but NONE is latest version!
> > Not a single one! 
> > 
> >   I propose to go back to the good old times when the Qt online SDK was
> >   safe
> > 
> > and helpful.
> > 
> > 
> >   I'm not against to have a chooice to install a specific version, what
> >   I'd like is
> 
> > to install e.g. 5.12 version and the online installer will update it with
> > the latest
 5.12.x version automatically.
> > 
> >  If an user, for some reason, want's to install a specific version he can
> >  pick it
> 
> > from new "Archive" section.
> > 
> > 
> >   As I commented in
> >   https://blog.qt.io/blog/2019/04/11/updated-qt-installer-> > 
> > released/,  as a Qt maintainer, I wonder quite often, if it's worth to
> > spend
 time to fix bugs that will go in revision/micro versions as long
> > as even I, as a Qt maintainer, don’t use them! I imagine that the
> > percentage of Qt users that are using the latest Qt versions is very low…
> > 
> > 
> >   Having said that, pretty please with sugar on top consider to add the
> > 
> > needed support to help the users to always use the latest and the safest
> > Qt
 version.
> > 
> > 
> > Cheers,
> > BogDan.
> > 
> > 
> > ___
> > 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

[Development] Qt online SDK security problems

[BogDan Vatra via Development]

Hi,

  Long time ago the Qt online SDK used to help the users to use the latest and 
the safest Qt version all the time. Sadly that was changed, IMHO without too 
much thinking, and now a lot of users (I'm one of them) are stucked with 
outdated versions. A few days ago I installed 5.12.2 and today suprise is 
outdated again.  It’s just ridiculously, I have five 5.9.x, 5.10.0, two 5.11.x 
and three 5.12.x versions, but NONE is latest version! Not a single one!

  I propose to go back to the good old times when the Qt online SDK was safe 
and helpful.

  I'm not against to have a chooice to install a specific version, what I'd 
like is to install e.g. 5.12 version and the online installer will update it 
with the latest 5.12.x version automatically.
 If an user, for some reason, want's to install a specific version he can pick 
it from new "Archive" section.

  As I commented in 
https://blog.qt.io/blog/2019/04/11/updated-qt-installer-released/,  as a Qt 
maintainer, I wonder quite often, if it's worth to spend 
time to fix bugs that will go in revision/micro versions as long as even I, as 
a Qt maintainer, don’t use them! I imagine that the percentage of Qt users 
that are using the latest Qt versions is very low…

  Having said that, pretty please with sugar on top consider to add the needed 
support to help the users to always use the latest and the safest Qt version.


Cheers,
BogDan.


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

Re: [Development] A deployment tool for Linux

[Bogdan Vatra via Development]

Hi,

  Personally I think it's a great idea. I used linuxdeployqt myself and it 
worked. The only problem I saw it was the speed, it takes quite a lot to 
complete (e.g. it took a few minutes, while androiddelopqt takes less than 10 
seconds). But witl some love I'm pretty sure it can be improved a lot.

Cheers,
BogDan.


În ziua de miercuri, 10 aprilie 2019, la 11:13:01 EEST, Mitch Curtis a scris:
> What do people think about having a deployment tool for Linux? There is an
> existing community tool based on macdeployqt:
> 
> https://github.com/probonopd/linuxdeployqt/
> 
> The author has considered the idea in the past:
> 
> https://github.com/probonopd/linuxdeployqt/issues/84
> 
> A Jira suggestion to track it:
> 
> https://bugreports.qt.io/browse/QTBUG-74940
> 
> ___
> 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

Re: [Development] Nominating Brett Stottlemeyer for Approver status

[Bogdan Vatra via Development]

+1

În ziua de luni, 18 martie 2019, la 10:05:22 EET, Ville Voutilainen a scris:
> Brett is the maintainer of Qt Remote Objects. Thus he should be 
> documented as a maintainer, and should also be an approver. Brett has 
> been effectively maintaining QRO since 2014, so it seems like a slam 
> dunk to give him the rights.
> ___
> 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

Re: [Development] Qt 5.12 branch is broken for Android

[Bogdan Vatra via Development]

Hi,

[...]
> > Now configure mixes host libs with the target (android) ones, which IMHO
> > is
> > very wrong when cross-compiling :).
> > Can some qmake master take a look and fix the problem?
> 
> if you're sure you have the latest revision and a completely clean build
> tree (including no stray .qmake.cache/.stash/.super files there or
> up-tree), make a _proper_ bug report on jira and make sure it's assigned
> to me.
> that applies to any _recent_ regressions introduced by me.

Done https://bugreports.qt.io/browse/QTBUG-72834 , though I have no idea if 
any of your patches caused this problem. I'm not blaming anyone for this 
problems, I'm just crying for help :).

Cheers,
BogDan.


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

[Development] Qt 5.12 branch is broken for Android

[Bogdan Vatra via Development]

Hi,

  I'm trying to compile Qt for Android and 5.12 branch received quite a lot 
configure changes which broke Android builds (though I thought that 5.12 branch 
is for bug fixes only).
 Now configure mixes host libs with the target (android) ones, which IMHO is 
very wrong when cross-compiling :).
Can some qmake master take a look and fix the problem?

Cheers,
BogDan.

P.S. 5.12.0 branch compiles with no problems


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

Re: [Development] Build system for Qt 6

[Bogdan Vatra via Development]

Hi,

În ziua de luni, 12 noiembrie 2018, la 15:06:00 EET, Joerg Bornemann a scris:
> On 10/30/18 12:16 PM, Bogdan Vatra via Development wrote:
> 
> Late to the game, but I feel the urge to comment on some things.
> 
> 
> > c.2) Incomplete! A while ago, I created a QBS plugin for KDevelop[1] and
> > I
> > found some problems, see how QBS developers treat them here: https://
> > bugreports.qt.io/browse/QBS-902 . That was the moment when I started to
> > have doubts :).
> 
> 
> This bug report is lacking crucial information to handle it properly, 
> like what's the expected outcome etc.
> As you are known as a seasoned developer we felt you didn't need the 
> https://wiki.qt.io/Reporting_Bugs link.
> 

  Even the whole discussion is futile now, can you pretty please tell me what 
"crucial information" are those issues missing? IMHO the titile of each issue 
is more than enough for any QBS developer.

> 
> > d) While c.1 and c.2 can be fixed with some effort, here we have bigger
> > problems:
> > 
> >- Instread to port QBS to QML JS in the first second when QtScript was
> > 
> > deprecated, they fork it! I know that back then QML JS needed some love,
> > but instead to collaborate with QML JS folks they decided keep using
> > QtScript!
> 
> QtScript was never forked. It even was included as git submodule at some 
> point. Unaltered.
> 

  This is very funny! did you included it as git submodule just because you 
like submodules?

> 
> > IIRC a brave soul, port it to QML JS, but guess what, QBS devs reject it
> > and kept using QtScript!
> 
> 
> You're remembering incorrectly.

Might be... If I'll have time I'll check it.

> There was never such a port.
> 
> 
> >   - Even more, they found a few problem also in QML parser, and guess
> >   what,
> > 
> > they forked also QML!
> 
> 
> The QML parser was never forked. It always has been a copy of the QML 
> parser, because we didn't want a dependency to the QtQml module.
> 
Again this is very funny: you didn't fork it, you copy it that's a huge 
diference :).

Sadly, in this moment it's too late to continue discussions on this matter...

Cheers,
BogDan.


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

Re: [Development] Build system for Qt 6

[Bogdan Vatra via Development]

Hi,

Yes, "hard to work with" :).

Cheers,
BogDan.

În ziua de joi, 1 noiembrie 2018, la 11:24:29 EET, Vlad Stelmahovsky a scris:
> you mean "hard to work with"?
> 
> On 11/1/18 9:34 AM, Bogdan Vatra via Development wrote:
> > Hi,
> > 
> >GN is the closest build system to QBS, the only problem it has it's
> > 
> > controled by Google and these guys are sometime had to work with.
> > 
> > Cheers,
> > BogDan.
> > 
> > În ziua de joi, 1 noiembrie 2018, la 10:30:01 EET, Nikolai Kosjar a scris:
> >> On 10/29/18 1:17 PM, Lars Knoll wrote:
> >>> Given that we are confident we can build Qt 6 with cmake, I believe that
> >>> it makes most sense to follow down that route.
> >> 
> >> Just some observation:
> >> 
> >> LLVM/Clang is a bigger project using CMake for some longer time and
> >> coincidentally, just now, there is a discussion whether they should add
> >> GN build files to their repositories as, let me quote:
> >> 
> >> """
> >> cmake is great for many use cases, but in my opinion local day-to-day
> >> development isn't one of them.
> >> """
> >> 
> >> Clang: https://lists.llvm.org/pipermail/cfe-dev/2018-October/060006.html
> >> LLVM: https://lists.llvm.org/pipermail/llvm-dev/2018-October/127342.html
> >> 
> >> Nikolai
> >> ___
> >> Development mailing list
> >> Development@qt-project.org
> >> http://lists.qt-project.org/mailman/listinfo/development
> > 
> > ___
> > Development mailing list
> > Development@qt-project.org
> > http://lists.qt-project.org/mailman/listinfo/development
> 
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development



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

Re: [Development] Build system for Qt 6

[Bogdan Vatra via Development]

Hi,

  GN is the closest build system to QBS, the only problem it has it's 
controled by Google and these guys are sometime had to work with.

Cheers,
BogDan.

În ziua de joi, 1 noiembrie 2018, la 10:30:01 EET, Nikolai Kosjar a scris:
> On 10/29/18 1:17 PM, Lars Knoll wrote:
> > Given that we are confident we can build Qt 6 with cmake, I believe that
> > it makes most sense to follow down that route.
> Just some observation:
> 
> LLVM/Clang is a bigger project using CMake for some longer time and
> coincidentally, just now, there is a discussion whether they should add
> GN build files to their repositories as, let me quote:
> 
> """
> cmake is great for many use cases, but in my opinion local day-to-day
> development isn't one of them.
> """
> 
> Clang: https://lists.llvm.org/pipermail/cfe-dev/2018-October/060006.html
> LLVM: https://lists.llvm.org/pipermail/llvm-dev/2018-October/127342.html
> 
> Nikolai
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development



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

Re: [Development] Build system for Qt 6

[Bogdan Vatra via Development]

Hi,

În ziua de marți, 30 octombrie 2018, la 19:11:20 EET, Oswald Buddenhagen a 
scris:
> On Tue, Oct 30, 2018 at 01:16:43PM +0200, Bogdan Vatra wrote:
> > c.2) back then, none of the existing build system could deliver enough
> > information to IDEs to enable prefect code completion (e.g.  include
> > paths, defines, compiler flags, etc.)
> > ...
> > c.2) Incomplete! A while ago, I created a QBS plugin for KDevelop[1]
> > and I found some problems, see how QBS developers treat them here:
> > https://bugreports.qt.io/browse/QBS-902 . That was the moment when I
> > started to have doubts :).
> 
> for all i can tell that's a rather poor bug report with little followup
> from you. that's where i start to have doubts whether you actually mean
> it. ;)
> 
You must be kidding! What do you want me to do more? Write some love poems?

>
> > d) last but not least a clean and easily maintainable code base that can
> > be
> > used for the next decade(s).
> > ...
> > 
> >   - Instread to port QBS to QML JS in the first second when QtScript was
> > 
> > deprecated, they fork it! I know that back then QML JS needed some love,
> > but instead to collaborate with QML JS folks they decided keep using
> > QtScript! IIRC a brave soul, port it to QML JS, but guess what, QBS devs
> > reject it and kept using QtScript!
> > 
> >  - Even more, they found a few problem also in QML parser, and guess what,
> > 
> > they forked also QML!
> 
> both these items get a huge "so what?" in response. because they have no
> practical impact whatsoever.
"So what?" Qt 6 will use cmake instead of qbs?
They have a big impact when it's comming to maintainanace. Instead to focus on 
qbs code, you have to focus also on QtScript and on QML parser...

> 
> > To fix d) a large part of QBS must be reorganized/rewritten,
> 
> i see no actual evidence of that.
Well, Qt 6 using cmake instead of qbs is the best *indirect* evidence ;-).


  Anyway, as long as Lars & Tuukka announced that qbs is dead, personally I 
think in this moment the whole discussion is futile. Because of that 
decission, in this moment TQC imagine is not very good, imagine how it will 
look if in a week or two you'll announce that you ditch cmake or qmake and 
embrace QBS again, that will be a PR nightmare and I don't see it coming :).

Cheers,
BogDan.


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

Re: [Development] Build system for Qt 6

[Bogdan Vatra via Development]

Hi,

DISCLAIMER: I was one of the biggest QBS supporters!

QBS was a dream too good to be true, its main goals were:
a)  a simple sintax which anyone can use
b) no extrenal dependeincies to configure/build & deploy your apps
c)  designed with tooling in mind: 
   c.1) imagine a world where you can manage almost everything in your project 
from IDE but also from your text editor.
  c.2) back then, none of the existing build system could deliver enough 
information to IDEs to enable prefect code completion (e.g. include paths, 
defines, compiler flags, etc.)
d) last but not least a clean and easily maintainable code base that can be 
used for the next decade(s).

Now let's see what QBS achived from all of these goals:
a) Checked, with minor things that we can leave with (the base.concat things I 
never undersood it). 
b) We can say checked.
c.1) Nope, not really. Besides that you can add files, you can't manage no 
other things. Here CMake is better, because it exposes all its properties in a 
IDE friendly way.
c.2) Incomplete! A while ago, I created a QBS plugin for KDevelop[1] and I 
found some problems, see how QBS developers treat them here: https://
bugreports.qt.io/browse/QBS-902 . That was the moment when I started to have 
doubts :).
d) While c.1 and c.2 can be fixed with some effort, here we have bigger 
problems:
  - Instread to port QBS to QML JS in the first second when QtScript was 
deprecated, they fork it! I know that back then QML JS needed some love, but 
instead to collaborate with QML JS folks they decided keep using QtScript! 
IIRC a brave soul, port it to QML JS, but guess what, QBS devs reject it and 
kept using QtScript!
 - Even more, they found a few problem also in QML parser, and guess what, 
they forked also QML!

To fix d) a large part of QBS must be reorganized/rewritten, so, IMHO this 
project is quite DEAD, because I don't believe the community will rewrite 
those parts.

Looking at these facts, I think TQC decission is not that bad and if they want 
to start working on Qt6 soon, they had to choose a build system now, and sadly 
cmake was the only choice...

Cheers,
BogDan.

[1] https://github.com/bog-dan-ro/kdevelop


În ziua de marți, 30 octombrie 2018, la 11:00:18 EET, Christian Gagneraud a 
scris:
> On Tue, 30 Oct 2018 at 01:17, Lars Knoll  wrote:
> > Hi all,
> 
> Hi Lars,
> 
> Playing the devil's advocate here.
> 
> May I ask: Which democratic/meritocratic  process was used to take
> this decision?
> I do understand that the QtC is the Qbs instigator/maintainer, so
> nobody can blame you for pulling the plug off and adjusting resources
> allocation.
> 
> Who/when/where was the decision of switching to CMake taken?
> Any trace record? A vote, a ballot, something? I havent's hear of any
> "Qt Project" event/announcement recently.
> So far i've seen some broad (but useful) un-authoritative requirements
> from Thiago,
> followed by a lengthy (endless) discussion, and suddenly your email
> that seems to announce the result of the "election".
> When did the election happened?
> 
> So some claims that build systems are no "The Qt Company" business,
> yet you're about to take the road of having to bend a dinosaur (CMake,
> that's a personal opinion) to suit your modern requirements.
> Are you planning to have Qt employees fix CMake?
> 
> Then why spend energy/money to fix something that is broken by design?
> (Again, that is a personal opinion, if needed to say)
> 
> No conspiracy here, but i have a few more questions (not related, in
> no particular order)
> - Did Jake left the QtC due to your early decision to drop qbs? ( I
> personally do think that the decision was taken long time ago)
> - Did you drop Qbs due to it's "unsolvable" dependency on deprecated Qt
> Script? - Any track record that Qbs was not fit for the job? (Please no "we
> can't build Qt with it", as you cannot build Qt with anything but
> qmake right now)
> 
> Sincerely,
> Chris



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

Re: [Development] Build system for Qt 6

[Bogdan Vatra via Development]

Yup, it's a sad day for people who liked QBS. Personally I'll check GN, which 
has a nice syntax, not as nice as QBS but ... :) .

În ziua de luni, 29 octombrie 2018, la 18:32:11 EET, Ray Donnelly a scris:
> Agreed, a brilliant bit of technology, such a shame to see it deprecated.
> 
> On Mon, Oct 29, 2018 at 4:24 PM Corentin  wrote:
> > Having had the pleasure to use QBS quite extensively (and successfully) in
> > the past, I would like to thank the QBS team and contributors for showing
> > us what a sane, modern build system could look like. So long!
> > 
> > On Mon, 29 Oct 2018 at 13:17 Lars Knoll  wrote:
> >> Hi all,
> >> 
> >> As you will probably remember, there have been lively discussions around
> >> what kind of build tool to use for Qt 6 both during Qt Contributor
> >> Summits as well as on this mailing list.
> >> 
> >> There has been a strong consent that we should move away from qmake as
> >> our build tool for Qt due to many shortcomings and the burden we have
> >> maintaining the system.
> >> 
> >> Thiago wrote a set of relatively strict requirements for such a build
> >> tool in his mail in July. While some of the requirements had a bit of a
> >> Linux specific background, they have been a good basis.
> >> 
> >> There have been rather lively discussions around alternatives, but most
> >> focused around two possible choices for us: Qbs and cmake.
> >> 
> >> Qbs is something that has been developed almost exclusively by The Qt
> >> Company. As such, TQtC had to also look at it from a business
> >> perspective and how it fits into the larger picture of making Qt
> >> successful. To make a long story short, while Qbs is pretty cool and
> >> interesting technology, it doesn’t really help us expand the Qt
> >> ecosystem and usage.
> >> 
> >> To make Qbs really successful would require a rather large effort and
> >> investment in promoting it towards the larger C++ ecosystem as a new
> >> build tool. At the same time it has to be an open source product to
> >> stand any chance in the market. Together this makes it challenging for
> >> TQtC to see how to recover that investment. Thus this investment would
> >> be at the expense of other things we’d like to do, like improving our
> >> IDE, working on rearchitecting and cleaning up our core frameworks for
> >> Qt 6 or the design tooling we are currently investing into. The Qt
> >> Company believes that those other investments are more important for the
> >> future of Qt than our choice of build tool.
> >> 
> >> As such, we were left with the question on whether we need Qbs as the
> >> build system for Qt 6 or whether cmake (as the other alternative) would
> >> be up to the task.
> >> 
> >> Given that background, we’ve done some more research on using both Qbs
> >> and cmake to build Qt. Both projects did give us good results but we
> >> were actually surprised on how far we got with cmake in a rather limited
> >> period of time.
> >> 
> >> In addition, cmake has the advantage of being very widely used in the C++
> >> ecosystem (amongst many others by KDE), has a very wide support in many
> >> IDEs and other tools (e.g. VCPkg, Conan etc.), and there’s a lot of
> >> knowledge about the build system available in the ecosystem. Using it
> >> with Qt 6 would also mean that we can focus our support on two build
> >> systems for our users (qmake and cmake) and we would not have to add a
> >> third one to the mix.
> >> 
> >> Given that we are confident we can build Qt 6 with cmake, I believe that
> >> it makes most sense to follow down that route. In case you’re
> >> interested, you can have a look at the cmake prototype code for qtbase
> >> on Gerrit in the wip/cmake branch. Please also let us know if you’re
> >> interested in helping with the effort of porting Qt’s build system over
> >> to cmake.
> >> 
> >> We have been developing Qbs over the last years, and as such are
> >> committed to it for some more time. We are planning on another feature
> >> release in the first quarter of next year and will support it in Qt
> >> Creator for at least another year. Qbs is open source and if someone
> >> wants to take over and develop it further let us know as well. I’d also
> >> like to use this place to thank Christian and Jörg for all their great
> >> work on Qbs  (and of course also anybody else who contributed to it).
> >> 
> >> Cheers,
> >> Lars
> >> ___
> >> Development mailing list
> >> Development@qt-project.org
> >> http://lists.qt-project.org/mailman/listinfo/development
> > 
> > ___
> > Development mailing list
> > Development@qt-project.org
> > http://lists.qt-project.org/mailman/listinfo/development
> 
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development



___
Development mailing list
Development@qt-project.org

Re: [Development] Qt 6 buildsystem support requirements

[BogDan Vatra via Development]

În ziua de joi, 2 august 2018, la 18:06:02 EEST, Thiago Macieira a scris:
> On Wednesday, 1 August 2018 23:13:13 PDT BogDan Vatra via Development wrote:
> > > Now that is nice, as we know that the moc, uic, rcc outputs are
> > > platform-
> > > independent. That should help reduce the build times on Windows for
> > > debug-and- release builds, as running moc is a significant portion of
> > > the
> > > build time.
> > > 
> >   It will be nice if this feature is mandatory for Qt 6, so let's add it
> >   to
> > 
> > your requirements list.
> 
> No, this is "nice to have", not mandatory. A reduction in build time would
> be very welcome, but if we don't have it, the build still works.
> 
> >   BTW, not only moc, uic & rcc are platform-independent, but also the
> > 
> > headers (except a few that are generated by configure script which can be
> > moved to platform libs dir). What will be cool really is to unify headers,
> > examples & demos for the Qt SDKs, this way we'll save a lot of space.
> 
> Sorry, I didn't get it. Can you clarify?

Sorry it's kinda off-topic. What I wanted to say is for Qt 6 to have a new SDK 
folders layout. Now each Qt target goes into a separate folder, but the bin, 
include (except a few files), doc, mkspecs, etc. folders are the same. The 
only platform-dependent folders are lib, plugins and qml.
So, instead of:

~/Qt
/5.11.1
  /android_armv7
/bin
/include
/lib
  /gcc_64
/bin
/include
/lib

we'll have:

~/Qt
/6.0.0
  /bin
  /include
  /lib
 /android_armv7 <-- here goes android armv7 libs
/include <-- here goes only android specific headers
/gcc_64 <-- here goes linux amd64 libs
   /include <-- here goes only  linux 64 specific headers

Platform specific headers are those that are generated by configure script.
Of curse the build system must handle this new layout.

Cheers,
BogDan.

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

Re: [Development] Qt 6 buildsystem support requirements

[BogDan Vatra via Development]

În ziua de joi, 2 august 2018, la 11:02:30 EEST, Lars Knoll a scris:
> > On 2 Aug 2018, at 09:52, BogDan Vatra  wrote:
> > 
> > În ziua de joi, 2 august 2018, la 09:49:48 EEST, Lars Knoll a scris:
> > 
> >>> On 2 Aug 2018, at 08:13, BogDan Vatra via Development
> >>>  wrote:
> > 
> > […]
> > 
> >>> 
> >>> It will be nice if this feature is mandatory for Qt 6, so let's add it
> >>> to
> >>> 
> >>> 
> >>> your requirements list.
> >> 
> >> 
> >> 
> >> 
> >> Let’s be careful not to add too many requirements upfront or we’ll never
> >> get
 anywhere.
> > 
> > 
> > [...]
> > 
> > Well, if we want to have first class Qt on Android support, this feature
> > is a 
 must. Now, if we can use it also for other platforms that's a
> > bonus.
> 
> Which feature exactly? Creating binaries for multiple targets in on compile
> run? Or also only calling rcc once?
 
> The first one I can see, the second one would be just an optimisation when
> creating multiple binaries.
 
First one.


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

Re: [Development] Qt 6 buildsystem support requirements

[BogDan Vatra via Development]

În ziua de joi, 2 august 2018, la 09:49:48 EEST, Lars Knoll a scris:
> > On 2 Aug 2018, at 08:13, BogDan Vatra via Development
> >  wrote:
 […]
> > 
> >  It will be nice if this feature is mandatory for Qt 6, so let's add it to
> >  
> > 
> > your requirements list.
> 
> 
> 
> Let’s be careful not to add too many requirements upfront or we’ll never get
> anywhere.
 
[...]

Well, if we want to have first class Qt on Android support, this feature is a 
must. Now, if we can use it also for other platforms that's a bonus.

Cheers,
BogDan.

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

Re: [Development] Qt 6 buildsystem support requirements

[BogDan Vatra via Development]

Hi
În ziua de joi, 2 august 2018, la 09:33:10 EEST, Joerg Bornemann a scris:
> On 08/02/2018 08:18 AM, Simon Hausmann wrote:
> > Given that the output of the moc changes depending on what platform and
> > compiler dependent pre-processor macros are supplied, I would say that
> > the output is not cross-platform.
> ...which is why qbs does *not* have such a feature.
> moc_XXX.cpp and XXX.moc files are generated per build configuration. The
> output is not shared.
> 

Right, moc files are not cross-platform but I think rcc & uic files are.

BogDan.

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

Re: [Development] Qt 6 buildsystem support requirements

[BogDan Vatra via Development]

Hi,
În ziua de joi, 2 august 2018, la 01:31:10 EEST, Thiago Macieira a scris:
> On Wednesday, 1 August 2018 12:46:04 PDT BogDan Vatra via Development wrote:
> > Hi,
> > 
> > qmake can't compile them all *at once* e.g. $ qmake && make will compile
> > only one target at the time not all.
> > 
> > AFAIK QBS and iirc gn too, are the only few that have this cool feature.
> 
> Now that is nice, as we know that the moc, uic, rcc outputs are platform-
> independent. That should help reduce the build times on Windows for
> debug-and- release builds, as running moc is a significant portion of the
> build time.

  It will be nice if this feature is mandatory for Qt 6, so let's add it to 
your requirements list.

  BTW, not only moc, uic & rcc are platform-independent, but also the headers 
(except a few that are generated by configure script which can be moved to 
platform libs dir). What will be cool really is to unify headers, examples & 
demos for the Qt SDKs, this way we'll save a lot of space.

Cheers,
BogDan.


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

Re: [Development] Qt 6 buildsystem support requirements

[BogDan Vatra via Development]

Hi,

qmake can't compile them all *at once* e.g. $ qmake && make will compile only 
one target at the time not all.

AFAIK QBS and iirc gn too, are the only few that have this cool feature.

Cheers,
BogDan.

On August 1, 2018 10:27:03 PM GMT+03:00, Thiago Macieira 
 wrote:
>On Wednesday, 1 August 2018 11:58:02 PDT BogDan Vatra via Development
>wrote:
>> Hi,
>> 
>>   Did you knew that qbs can build all but windows targets at once
>from your
>> Linux machine? 
>
>That's not news. qmake can do that, provided you have the toolchains.
>You 
>could compile for Mac and MSVC too, if you had them (for MSVC, via
>Wine, like 
>godbolt.org).
>
>> Using mingw you can cross compile Qt for windows, but you
>> probably want to run tests and to check if the code compiles with
>msvc.
>> This feature might not seem pretty useful for linux, but is very
>useful for
>> Android where we can bundle multiple platforms in the same package.
>
>Agreed.
>
>-- 
>Thiago Macieira - thiago.macieira (AT) intel.com
>  Software Architect - Intel Open Source Technology Center
>
>
>
>___
>Development mailing list
>Development@qt-project.org
>http://lists.qt-project.org/mailman/listinfo/development

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt 6 buildsystem support requirements

[BogDan Vatra via Development]

Hi,

  Did you knew that qbs can build all but windows targets at once from your 
Linux machine? Using mingw you can cross compile Qt for windows, but you 
probably want to run tests and to check if the code compiles with msvc.
  This feature might not seem pretty useful for linux, but is very useful for 
Android where we can bundle multiple platforms in the same package.


Cheers,
BogDan.

On August 1, 2018 7:37:13 PM GMT+03:00, Thiago Macieira 
 wrote:
>On Wednesday, 1 August 2018 02:01:40 PDT Edward Welbourne wrote:
>> This is easy to do in any build system that supports out-of-source
>> (a.k.a. "shadow") builds - notably including the existing qmake-based
>> builds for Qt.  I never want to do an in-source build of anything.
>
>And not just that. Building out-of-source is an absolute requirement.
>
>With one set of Qt sources, I build:
> - debug
> - release
> - clang release
> - icc release
> - i386 release namespace
> - MSVC 2017 (source dir is mounted read-only in the VM)
>
>Plus discontinued (used to build, haven't in over 2 years):
> - ARM 32-bit
> - MIPS 32-bit
> - static
>
>Ditto on the Windows machine, where the same set up, I build:
> - MSVC 2017 64-bit
> - MSVC 2015 64-bit
> - MSVC 2013 64-bit (will stop)
> - ICC 18 MSVC 2017 64-bit (configure only)
> - ICC 18 MSVC 2015 64-bit (only qtbase)
>
>And on the Mac, the same sources builds both frameworks and
>no-frameworks, 
>though I think I haven't built the latter in several years (unlike the
>Mac and 
>Windows laptops, the Mac machine is from 2012, so it has old stuff).
>
>-- 
>Thiago Macieira - thiago.macieira (AT) intel.com
>  Software Architect - Intel Open Source Technology Center
>
>
>
>___
>Development mailing list
>Development@qt-project.org
>http://lists.qt-project.org/mailman/listinfo/development

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Raising the minimum Android NDK version

[BogDan Vatra via Development]

For 5.11 we used 10e and I'm afraid we can't afford to change it without proper 
testing.

Cheers,
BogDan.

On July 29, 2018 10:11:53 PM GMT+03:00, Thiago Macieira 
 wrote:
>On Sunday, 29 July 2018 11:15:38 PDT BogDan Vatra via Development
>wrote:
>> AFIK qt 5.12 will use ndk r16 or better.
>
>The question was for Qt 5.11 using fixed headers.
>
>The fix in Bionic happened in January 2015.
>
>-- 
>Thiago Macieira - thiago.macieira (AT) intel.com
>  Software Architect - Intel Open Source Technology Center
>
>
>
>___
>Development mailing list
>Development@qt-project.org
>http://lists.qt-project.org/mailman/listinfo/development

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Raising the minimum Android NDK version

[BogDan Vatra via Development]

AFIK qt 5.12 will use ndk r16 or better.

On July 29, 2018 6:16:30 PM GMT+03:00, Thiago Macieira 
 wrote:
>On Monday, 16 July 2018 08:50:05 PDT Thiago Macieira wrote:
>> On Monday, 16 July 2018 00:08:44 PDT Bogdan Vatra via Development
>wrote:
>> > The clang support was added and works fine from 5.9. But I think is
>too
>> > late to switch NDK for 5.11.
>> 
>> I'm not asking to change compilers. I am asking whether we can
>require fixed
>> NDK headers?
>
>No answer.
>
>I've marked https://bugreports.qt.io/browse/QTBUG-69173 as unassigned
>and 
>abandoned the change that would fix.
>
>Someone else take care of Android. I'm tired of the buggy libc we have
>to deal 
>with, the fact that we can't even rely on the fixes from said libc and
>the 
>fact that there seems to be little attention to this platform from the
>people 
>who should be the experts.
>
>This is not the first time.
>
>-- 
>Thiago Macieira - thiago.macieira (AT) intel.com
>  Software Architect - Intel Open Source Technology Center
>
>
>
>___
>Development mailing list
>Development@qt-project.org
>http://lists.qt-project.org/mailman/listinfo/development

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt 6 buildsystem support requirements

[BogDan Vatra via Development]

Hi,
În ziua de duminică, 22 iulie 2018, la 12:18:06 EEST, Tobias Hunger a scris:
> On Sat, Jul 21, 2018, 14:49 Jean-Michaël Celerier <
> 
> jeanmichael.celer...@gmail.com> wrote:
> > +1, I was flabbergasted when the big objection against CMake in Qt 6
> > boiled down to "it does not supports all the architectures that Qt
> > supports",
> 
> IIRC the bid showstopper was that CMake does not support building host
> tools and the target libraries in one go.
> 
> That requirement was dropped since then in our side.
> 

Begin able to build for multiple platforms at once is a requirement also for 
Android where you can bundle multiple platforms at once in one package. Most 
probably Android is not the only one which supports this feature.
This feature is already implemented by QBS.

Cheers,
BogDan.

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

Re: [Development] Qt 6 buildsystem support requirements

[BogDan Vatra via Development]

Hi,
În ziua de duminică, 22 iulie 2018, la 12:11:44 EEST, Tobias Hunger a scris:
> On Sat, Jul 21, 2018, 07:38 Bogdan Vatra via Development <
> 
> development@qt-project.org> wrote:
> > You really hate QBS don't you ? :)
> 
> Do you have so few arguments for qbs that you need to appeal to emotions? :)
If it works why not, I'm using all the weapons I have. :-P 

>
>> Anyway IMHO is more important to have a clean, nice and easy to use syntax
> > and
> > to be tooling friendly than 1.b.
> 
> Sure you can write toolable build files with qbs, but there is nothing
> stopping you writing an unparsable JS mess either.

Hehe of course you can write messy JS, but at least it doesn't hurt your eyes 
when you read it and in the morning you don't wake up screaming.

> For QML we needed to define a toolable subset of the language with the UI
> files to have any chance at tooling it. For the qbs dialect of QML that has
> not been done yet. So I do not consider qbs to be toolable at this point.

By tooling friendly I mean basic stuff:
 - create (sub) projects, this part is mostly handled by QtCreator with the 
wizards templates, but the build system still needs to add it the the parent 
project.
 - add targets (executable, static & dynamic libs) to (sub) projects
 - add/remove files to a (sub)project target.
 - get all the info about every source file of the (e.g. all compiler flags), 
cmake with the server thing can handle this task properly these days.
 - parse the project and report in an easy for IDE way all the project parts 
(files, (sub) projects, targets, etc.). Same as above, thanks to cmake-server, 
QtCreator gets all the info properly.

Last time I checked it, QBS can handle all those things not only a few.

What QBS is missing are toolable properties (similar with cmake ones) which 
can be used to turn on/off different parts of the project or set other stuff 
needed by a big projects like Qt (e.g. git version).

Going much deeper than this, we'll have to either create super complicated 
parsers as you mentioned or we'll have to use xml/json/etc. in a non (easily) 
readable by humans forms.

Cheers,
BogDan.


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

Re: [Development] How would Android switching to Vulkan would impact Qt for Android?

[Bogdan Vatra via Development]

Hi,

În ziua de sâmbătă, 21 iulie 2018, la 11:06:30 EEST, Vincas a scris:
> Story:
> 
> https://www.xda-developers.com/google-android-q-vulkan-graphics-render-ui/
> 
> I wonder how it could affect QML apps built for Android?

It doesn't mean that OpenGL support will be removed, so there should be no 
problem for OpenGL apps.

Cheers,
BogDan.


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

Re: [Development] Qt 6 buildsystem support requirements

[Bogdan Vatra via Development]

Hi,
În ziua de sâmbătă, 21 iulie 2018, la 09:40:47 EEST, Allan Sandfeld Jensen a 
scris:
> On Samstag, 21. Juli 2018 07:38:10 CEST Bogdan Vatra via Development wrote:
> > Hi,
> > 
> > În ziua de sâmbătă, 21 iulie 2018, la 05:35:48 EEST, Thiago Macieira a
> 
> scris:
> > > Hello
> > > 
> > > Having spent far too much time trying to figure out why crappy
> > > buildsystems
> > 
> > [...]
> > 
> > > 1) Ease of obtention
> > > 
> > > a) Must be packaged by all major package managers where Qt 6 is expected
> > > to
> > > 
> > > be relevant. That is, it must be available as a package in:
> > >  - ArchLinux
> > >  - Debian testing
> > >  - Gentoo
> > >  - Fedora current and previous
> > >  - openSUSE current and previous
> > >  - Ubuntu LTS released more than 6 months prior
> > >  - Homebrew (macOS)
> > 
> > [...]
> > 
> > > b) Must be easily compiled from source on a standard system
> > > installation.
> > > All of its dependencies must come from the system's package manager and
> > > there must be no cyclic dependencies. That is, it cannot require itself
> > > to
> > > build and it must not depend on Qt, either in source form or binary.
> > 
> > You really hate QBS don't you ? :)
> > 
> > Anyway IMHO is more important to have a clean, nice and easy to use syntax
> > and to be tooling friendly than 1.b.
> > 
> > GN[1] is another example of build system which didn't care too much about
> > 1.a,b,c and it still used in quite big projects (e.g. chrome, fuchsia). To
> > my huge surprise, they managed to move it into a separate repo and remove
> > all chromium dependencies (yep, a few months ago you had to checkout the
> > entire chromium repo to build it :) ).
> 
> Sounds good, but at least for the last year it has also been so unstable
> that any older version of GN couldn't build a newer Chromium release, and
> all the build logic was heavily tied to how Chromium does this, and it has
> a bootstrapper than never worked in any releases ever, so the only way to
> build GN was to download GN and build it with the blackbox binary.
> 

Check the new repo, the bootstrap works ok now (if you don't have clang you'll 
need to apply https://gn-review.googlesource.com/c/gn/+/2340).

I'm not trying to sell GN here, because from my experience, Google folks are 
quite difficult to work with and not very open to changes. 
What I'm trying to sell here is QBS which I (still) believe is one of the best 
buildsystems out there and we should not ditch it just because can't be 
boostraped (easily?).

Cheers,
BogDan.


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

Re: [Development] Qt 6 buildsystem support requirements

[Bogdan Vatra via Development]

Hi,

În ziua de sâmbătă, 21 iulie 2018, la 05:35:48 EEST, Thiago Macieira a scris:
> Hello
> 
> Having spent far too much time trying to figure out why crappy buildsystems
[...]
> 
> 1) Ease of obtention
> 
> a) Must be packaged by all major package managers where Qt 6 is expected to
> be relevant. That is, it must be available as a package in:
>  - ArchLinux
>  - Debian testing
>  - Gentoo
>  - Fedora current and previous
>  - openSUSE current and previous
>  - Ubuntu LTS released more than 6 months prior
>  - Homebrew (macOS)
[...]
> 
> b) Must be easily compiled from source on a standard system installation.
> All of its dependencies must come from the system's package manager and
> there must be no cyclic dependencies. That is, it cannot require itself to
> build and it must not depend on Qt, either in source form or binary.

You really hate QBS don't you ? :)

Anyway IMHO is more important to have a clean, nice and easy to use syntax and 
to be tooling friendly than 1.b.

GN[1] is another example of build system which didn't care too much about 
1.a,b,c and it still used in quite big projects (e.g. chrome, fuchsia). To my 
huge surprise, they managed to move it into a separate repo and remove all 
chromium dependencies (yep, a few months ago you had to checkout the entire 
chromium repo to build it :) ).

Cheers,
BogDan.

[1] https://gn.googlesource.com/gn/


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

Re: [Development] Raising the minimum Android NDK version

[Bogdan Vatra via Development]

În ziua de vineri, 13 iulie 2018, la 23:50:36 EEST, Thiago Macieira a scris:
> On Wednesday, 11 July 2018 23:32:16 PDT Thiago Macieira wrote:
> > On Wednesday, 11 July 2018 23:00:50 PDT Liang Qi wrote:
> > > https://bugreports.qt.io/browse/QTQAINFRA-1681
> > > https://codereview.qt-project.org/#/c/216306/
> > > https://codereview.qt-project.org/#/c/229465/
> > > 
> > > People are working on that, hope will get update after summer vacations.
> > 
> > Thank you. Do I understand that the minimum version will be r16b?
> 
> Will this apply to 5.11? I need a decision on whether I need to work around
> NDK bugs.

The clang support was added and works fine from 5.9. But I think is too late 
to switch NDK for 5.11.

Cheers,
BogDan.

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

Re: [Development] Android binary size with Clang

[Bogdan Vatra via Development]

În ziua de joi, 21 iunie 2018, la 11:38:29 EEST, Sérgio Martins via 
Development a scris:
> On 2018-06-21 04:40, Thiago Macieira wrote:
> > Hello
> > 
> > Yesterday during the PDXCPP Meet Up, I was asked if we had come up with
> > a good
> > solution to the increase in size of native binaries on Android when
> > switching
> > from GCC to Clang. I reported I had no idea there was even a problem.
> > 
> > So, what's the status here?
> 
> -fno-exceptions was missing and someone discovered -Oz (you actually?),
> so it's not so bad now.
> Around 10% binary increase instead of 40% IIRC. QtXmlPatterns suffers
> much more than 10% for some reason though, so mileage might vary.
> 
> As far as qt-project is concerned the status is SOLVED IMHO. Users
> should pressure google directly for further improvement.
> 

Is not solved, at least not until we test also the speed, check https://
github.com/android-ndk/ndk/issues/495 

Cheers,
BogDan.


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

Re: [Development] QtCS 2018 - Serialisation session notes

[Bogdan Vatra via Development]

Hi,

> 
> === Protobuf ===
> 
> * Need volunteers to write a Proof of Concept
> ** plugin to protoc?

  IMHO flatbuffers (https://google.github.io/flatbuffers/) has quite a few 
advantages over protocol buffers (one that I really like is that the only 
dependency your app has is a single .h file, which makes it very portable).
Here https://github.com/bog-dan-ro/flatbuffers I have an old fork that adds Qt 
support to flatbuffers.

The only disadvantage that I found is that the maintainer was a little bit 
difficult to work with :).

Cheers,
BogDan.


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

Re: [Development] Fornux C++ Superset

[Bogdan Vatra]

Hi,

În ziua de marți, 24 aprilie 2018, la 04:08:19 EEST, Phil Bouchard a scris:
> Greetings,
> 
> Because Qt is very powerful, I would like to clarify the importance of
> the following problems despite my previous informal attempts:
> - The recent Qt 5.10.1 still randomly crashes for apps written on the
> iPhone and for the Android as well.

Is there any bug report(s) on this matter? 
Can you please provide some links(s) to the bug reports and a way to 
"randomly" reproduce these problems?
[...]

Cheers,
BogDan.


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

Re: [Development] Proposing David Faure as maintainer of Qt Models

[BogDan Vatra]

+1 from me.

Cheers,
BogDan.

În ziua de luni, 12 martie 2018, la 19:10:35 EET, Sérgio Martins a scris:
> Hi,
> 
> 
> Although the wiki says Qt Models don't have a maintainer I'd say David
> Faure has been an unofficial maintainer.
> David is one of the top contributors to model related code and is
> someone you'll always want to add as reviewer.
> 
> He's well known in the community and already maintains QtXmlPatterns, Qt
> mimetypes and Qt3Support.
> 
> Disclaimer: David works with me at KDAB.
> (And if you're wondering if KDAB has any plans for this module, the
> answer is no. In fact I hope it remains low change volume).
> 
> 
> Finally, a big thanks to the previous maintainer, Stephen Kelly, who did
> a great job, both on Qt and KDE models!
> 
> 
> Regards,

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

Re: [Development] Qt branches & proposal how to continue with those

[Bogdan Vatra]

Hi,

  As long as we don't have enough time fix all the problems in a non LTS 
release, I think releasing at least one patch version is not that bad ...

Yours,
BogDan.

În ziua de luni, 29 ianuarie 2018, la 10:15:51 EET, Simon Hausmann a scris:
> Hi,
> 
> 
> I feel that we are generally guiding our users towards the LTS releases. The
> minor releases appear to address in particular users who need a particular
> feature before it hits the next LTS release.
> 
> 
> In the light of that, I think it would be better to keep the LTS branches
> open longer and stop doing patch releases for minor releases that are not
> LTS.
> 
> 
> 
> Simon
> 
> 
> From: Development 
> on behalf of Jani Heikkinen  Sent: Monday, January
> 29, 2018 7:59:06 AM
> To: development@qt-project.org
> Subject: [Development] Qt branches & proposal how to continue with those
> 
> Hi,
> 
> We have currently really many branches open:
> - 5.6
> - 5.9
> - 5.10
> - 5.10.1
> - 5.11
> - dev
> 
> In my opinion this is too much to handle effectively, especially because
> there is many branches in stable mode (see
> http://code.qt.io/cgit/meta/quips.git/tree/quip-0005.rst). Currently '5.6'
> is in 'strict' mode and  '5.9', 5.10' & '5.11' are in stable... I think we
> need to change that to be able to work efficiently & get releases out.
> 
> So I am proposing following changes starting from 1st Feb 2018:
> 
> - '5.6' will move in 'very strict' mode
> - '5.9' will move in 'strict' mode. So no direct submissions anymore, just
> cherry picks from stable - '5.10' will be closed and Qt 5.10.1 will be the
> final release from Qt 5.10 series (5.6 and 5.9 are LTS branches so we
> shouldn't keep Qt 5.10 active too long) - '5.11' will be to one and only
> stable branch
> 
> br,
> 
> Jani
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

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

Re: [Development] Time to switch to android-clang

[BogDan Vatra]

On marți, 19 decembrie 2017 11:25:17 EET Sergio Martins wrote:
[...]
> 
> The problem of clang generating bigger binaries was much improved with
> -Oz, now size increase is only 10%.
> 
Which, on ARM, usually means the bins are slower ;-)
[...]

Anyway, a +0.5 also from my side.

Cheers,
BogDan.

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

Re: [Development] Nominating Kevin Funk for Maintainer qtbase/Build Systems/CMake

[Bogdan Vatra]

On vineri, 13 octombrie 2017 21:30:59 EET André Pönitz wrote:
> Hi all.
> 
> I would like to nominate Kevin Funk for Maintainer of the
> Build Systems/CMake area.
> 
> Kevin is effectively doing the job today.
> 

+1 from me!

Cheers,
BogDan.

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

Re: [Development] Future of QBS

[BogDan Vatra]

On luni, 16 octombrie 2017 17:38:53 EEST Christian Gagneraud wrote:
> On 16 October 2017 at 15:42, Kevin Kofler  wrote:
> > Christian Gagneraud wrote:
> >> I would resume this post as "I love CMake, CMake is the only way.
> >> You're all wrong."
> >> This post doesn't explain anything, doesn't gives any analysis, no
> >> comparison, no argument whatsoever, nothing.
> > 
> > It makes one important point (and elaborates it to great lengths):
> > developer familiarity. Even if QBS were actually a lot better than CMake
> > (something I am also very sceptical about), it would still be universally
> > hated simply because it is not what developers (and distribution
> > packagers!) know.
> Universally, really? In your world maybe, not in mine.
> 
> Anyway, I think the discussion is turning sterile, at least for me.
> You are free to make your own choice, and so am I.
> 
> In case my wording sounded harsh, I would like to let you know that I
> am genuinely happy for you to be in charge of CMake support, I mean
> it.
> 

"Kevin Kofler" != "Kevin Funk" ...

Whatever you're smoking, I want some too ;-) !

Cheers,
BogDan.

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

Re: [Development] Proposal for Qt 5.10 platforms and configurations changes

[Bogdan Vatra]

Hi Jake,

On joi, 27 aprilie 2017 15:00:58 EEST Jake Petroules wrote:
> > On Apr 27, 2017, at 7:40 AM, BogDan Vatra <bogdan.va...@kdab.com> wrote:
> > 
> > For Android I'd like to support 64 bit platforms (arm and x86)
> 
> 
> They are already supported. Feel free to compile Qt with the appropriate
> -arch options. 
I know about that option, because, well, I implement it :).

> Do you mean you want them in CI and want us to start
> shipping binaries for android amd64 and arm64?
Yes, this is what I mean!

> I'm not sure there's enough 64-bit devices out there to justify it yet.
> Android moves very slow...
My hunch is that in 2016 there were shipped more Android arm64 devices than 
iOS ones ;-).

x86_64 bins will be used only for chromebooks, though it seems google is 
moving way from x86 also on chromebooks, so x86_64 are low priority.

Cheers,
BogDan.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Proposal for Qt 5.10 platforms and configurations changes

[BogDan Vatra]

For Android I'd like to support 64 bit platforms (arm and x86)

BogDan.

On April 27, 2017 12:29:08 PM GMT+03:00, Heikki Halmet  
wrote:
>Hi,
>
>
>
>Below we have proposal for changes in supported platforms and
>configurations from Qt 5.9 to 5.10.
>
>Please comment if the proposal is insufficient or the changes are
>unacceptable somehow.
>
>
>
>Please refer to Qt 5.9 Supported platforms ->
>http://doc-snapshots.qt.io/qt5-5.9/supported-platforms.html
>
>
>
>LIST OF PROPOSAL CHANGES FROM 5.9 TO 5.10:
>
>RHEL 7.2 -> RHEL 7.3 (Any benefits?)
>
>OpenSUSE 42.1 -> OpenSUSE 42.2
>
>Ubuntu 17.04 (Ubuntu 16.04 lts will stay in CI)
>
>macOS 10.11 xcode 8.2 -> xcode 8.2.1 (or the latest available)
>
>macOS 10.12 xcode 8.2.1 -> xcode 8.3.1 (or the latest available)
>
>Windows 7 MinGW 5.3.0 -> MinGW 6.3.0
>
>Embedded Linux (Boot2Qt) Yocto 2.2.1 & gcc 6.2 -> Yocto 2.3 & gcc 6.3
>
>INTEGRITY GHS 2016.5.4 -> 2017.1.x
>
>Support for Android 8 (if available on time)
>
>iOS 11 support (if available on time. Current rumors -> september)
>
>
>
>MacOS 10.13 will be released September 2017 hopefully. Feature Freeze
>for 5.10 is at the beginning of August.
>
>This means that we can only use Preview release of 10.13 for testing
>before final official release is out.
>
>That can cause situation that we don't have enough time to get 10.13 in
>before 5.10 release so we can't give guarantees that 10.13 will be
>supported in 5.10.
>
>
>
>NOTE! We will commit to wanted platform and software changes as long as
>those are available straight after 5.9 release is out in the end of the
>May.
>With all others we'll do the best we can but we can't commit that those
>will be supported in 5.10.
>
>
>
>Best regards
>Heikki Halmet
>
>The Qt Company, Elektroniikkatie 13, 90590 Oulu, Finland
>Email: heikki.hal...@qt.io
>Phone: +358408672112
>www.qt.io | Qt Blog: http://blog.qt.io/ | Twitter:
>@qtproject, @Qtproject Facebook:
>www.facebook.com/qt

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt 5.10 schedule proposal

[Bogdan Vatra]

On joi, 13 aprilie 2017 12:34:27 EEST Tuukka Turunen wrote:
> On 13/04/2017, 15.30, "Development on behalf of Konstantin Tokarev"
> <development-bounces+tuukka.turunen=qt...@qt-project.org on behalf of
> annu...@yandex.ru> wrote:
 
> 
> 
>     13.04.2017, 15:11, "Bogdan Vatra" <bogdan.va...@kdab.com>:
> 
> > It's just me or did you forgot to add 5.8.1?
> 
> 
> I think I hear how Mr. Turunen is pulling his hair out reading this :)
> 
> Yes, quite right. 
> 

My colleagues told me all the story, what I don't understand is why 5.8 branch 
is not closed. I just pushed quite a few patches in that branch ...

BogDan.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt 5.10 schedule proposal

[Bogdan Vatra]

It's just me or did you forgot to add 5.8.1?

Cheers,
BogDan.

On joi, 13 aprilie 2017 11:48:06 EEST Jani Heikkinen wrote:
> After short internal discussion here is my proposal for those patch level
> releases:
> 
> - Branch '5.6.3' from '5.6' at the end of May/beginning of June, 5.6.3
> release target August 2017 - Branch '5.9.1' from '5.9' at the end of
> July/beginning of August, 5.9.1 release target September 2017 - Branch
> '5.9.2' from '5.9' Nov 2017
> - Branch '5.6.4' from '5.6' Jan 2018
> 
> br,
> Jani
> 
> > -Original Message-
> > From: Development [mailto:development-bounces+jani.heikkinen=qt.io@qt-
> > project.org] On Behalf Of Thiago Macieira
> > Sent: maanantaina 10. huhtikuuta 2017 18.46
> > To: development@qt-project.org; releas...@qt-project.org
> > Subject: Re: [Development] Qt 5.10 schedule proposal
> > 
> > Em segunda-feira, 10 de abril de 2017, às 00:39:09 PDT, Jani Heikkinen
> > 
> > escreveu:
> > > Hi,
> > > 
> > > Qt 5.9 is proceeding quite well and it is time to start planning Qt
> > > 5.10 schedule. We want to to release 5.10 before Christmas so we need
> > > to have Qt
> > > 5.10 FF at the beginning of August. I propose following initial
> > > schedule for Qt 5.10:
> > > 
> > > - Qt 5.10 Feature Freeze: 8.8.2017
> > > - Qt 5.10 Alpha Release: 31.8.2017
> > > - First Qt 5.10 Beta Release 5.10.2017
> > > - Qt 5.10 RC 16.11.2017
> > > - Qt 5.10 final release 30.11.2017
> > 
> > Can you add the Qt 5.6.3, 5.6.4 and 5.9.1 relase dates to the list, so we
> > have an idea of how much work it will be?
> > 
> > --
> > Thiago Macieira - thiago.macieira (AT) intel.com
> > 
> >   Software Architect - Intel Open Source Technology Center
> > 
> > ___
> > Development mailing list
> > Development@qt-project.org
> > http://lists.qt-project.org/mailman/listinfo/development
> 
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development


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

Re: [Development] Nominate Mike Krus as approver

[Bogdan Vatra]

On luni, 6 februarie 2017 12:26:03 EET Sean Harmer wrote:
> Hi,
> 
> I'd like to nominate Mike Krus as an approver. Mike contributed support for
> Qt on tvOS along with the refactoring that went in as part of this. Mike
> has done a lot of work within Qt 3D too.
> 
> Disclaimer: Mike is a colleague at KDAB.
> 
> Cheers,
> 
> Sean

+1

BogDan.

Same disclaimer.

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

Re: [Development] A new approach for Qt main()

[Bogdan Vatra]

On vineri, 9 decembrie 2016 12:58:46 EET Eskil Abrahamsen Blomfeldt wrote:
> Den 09.12.2016 12:40, skrev Tor Arne Vestbø:
> > On 09/12/2016 11:44, Lars Knoll wrote:
> >> Well, the problem is that the main() entry point is causing huge amounts
> >> of issues on at least Android and iOS.
> > 
> > I don't know about Android, but on iOS this is patently false. While
> > the workaround is complex, it has worked very well in the 3 years
> > since its inception. Please don't use iOS as a straw-man in this
> > discussion.
> 
> Speaking for Android, there are and have been thread synchronization
> issues due to Qt running a synchronous event loop in the main function.
> It is also impossible to make applications with multiple entry points
> and complex life cycles, which you would expect in an Android
> application consisting of several activities and services that can be
> triggered independently and simultaenously. Our work-around for this is
> to limit support to applications with one activity or one service per
> process in the application.
> 
> So while we have been able to find solutions for most our problems, both
> on Android and iOS, I guess Lars' point is that we are encountering more
> and more cases where we have to invent hacks and work-arounds and
> document limitations in order to be functional on modern platforms. It
> might be a sign that we should adapt.

IMHO (at least) for Android the biggest problem is the QPA architecture which 
is not designed for multiple Activities/Services. On Android we'll need a QPA 
instance for every Activities/Services :). This also means we'll need to 
redesign QtAndroidExtras as well.

Even if having  multiple Activities in the same process will be a nice thing, 
is not a very demanding feature. The most demanding feature will be to support 
multiple Services alongside an Activity in the same process.

Cheers,
BogDan.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QDataStream: blackbox or document all versions?

[Bogdan Vatra]

Hi,

What about Option 3 :) ?
Use another binary format for serialization: flatbuffers [1] which is super 
fast, has a stable binary format and can be used by lots of other languages 
[2].

Cheers,
BogDan.

P.S. On my personal fork [3] I even added Qt support, and it can be used from 
QML as well ;-)

[1] http://google.github.io/flatbuffers/
[2] http://google.github.io/flatbuffers/flatbuffers_support.html
[3] https://github.com/bog-dan-ro/flatbuffers

On sâmbătă, 24 septembrie 2016 20:58:38 EEST Thiago Macieira wrote:
> A thread[1] on the interest mailing list started when someone asked for the
> docs for the current format of the QDataStream wire protocol, to which I
> replied that it doesn't exist as we don't maintain such docs.
> 
> Long story short, we have two options:
> 
> Option 1: claim QDataStream is a blackbox and tell people that the only
> thing that can read QDataStream is QDataStream. That means removing the
> documentation file src/corelib/doc/src/datastreamformat.qdoc, as we don't
> want people getting any ideas that they could write their own decoders or
> encoders.
> 
> Option 2: the opposite, saying that reading QDataStream's output is fine
> from non-Qt code and it's fine to write data that QDataStream should read.
> This means extending the documentation to cover ALL 17 wire formats
> (including bugs) and keeping it up to date whenever someone modifies the
> format.
> 
> 
> I am in favour of Option 1 because I really don't think QDataStream is a
> good format for exchanging data with non-Qt code. It's designed first and
> foremost for Qt's own internal data formats (sometimes even depending on
> internal details), the marshalling of certain types in certain versions is
> buggy and lossy. Instead, people should find a better transport format for
> their data, of which we already have in Qt:
> 
>   XML
>   JSON
>   D-Bus
>   QSettings (to an extent)
> 
> And I can add CBOR support if we want to.
> 
> [1]
> http://lists.qt-project.org/pipermail/interest/2016-September/024387.html


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

Re: [Development] Notes on "Qt Build Systems" @ QtCon 2016

[BogDan Vatra]

On joi, 8 septembrie 2016 20:22:25 EEST Jake Petroules wrote:
> I just found a perfect example of how hard building a JAR file is in qmake
> for example, compared to qbs:

IMHO will be even easier if instead:
qbs-javac-scan.qbs:
[...]
files: [
"io/qt/qbs/**/*.java"
]
[...]

You'll write:
[...]
dirs: [
"io/qt/qbs/"
]
[...]

As any java developer is used to write in any java build system ;-)

Cheers,
BogDan.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Notes on "Qt Build Systems" @ QtCon 2016

[BogDan Vatra]

On marți, 6 septembrie 2016 17:35:03 EEST Cristian Adam wrote:
> On Tue, Sep 6, 2016 at 5:14 PM, Kevin Kofler  wrote:
> > I guess somebody could even get CMake to write Qbs files, it would just be
> > one more generator. :-)
> 
> This was done already
>  cb81da934c0>, but it was removed from CMake due to bad feedback from
> Qt Creator people.
> 

Ha ha ha! 
The guy who implemented this didn't know that QBS is not better than cmake 
when it comes to give proper information to IDE which is so needed to have 
proper syntax highlighting and code completion. For those who don't know yet, 
QBS *DOESN'T* provide the necessary info to the IDE:
- no compiler preprocessor defines: https://bugreports.qt.io/browse/QBS-903 
even is hallucinating this bug was closed as invalid :) there is a pending 
patch https://codereview.qt-project.org/#/c/122000/ which might fix it but 
we'll soon celebrate its 2nd anniversary in gerrit :)
- no system includes paths: https://bugreports.qt.io/browse/QBS-904 
- no c/cpp flags: https://bugreports.qt.io/browse/QBS-905

Having said that, why on earth to create such a generator when QBS support in 
QtCreator is the same (or even worst) than cmake's one?


DISCLAIMER: I was one of the biggest fans of this project, I had so much hopes 
for it, but when you have high hopes you'll also have high disappoints :) .
I'll try to summarize my thought on QBS:
- it still has HUGE potential, it has a great easy to use & learn syntax 

-it has great features that you can't find in other build systems (e.g. it can 
build multiple ABIs/platforms at once).

- personally I don't mind that it depends on Qt, what I do mind is that it 
depends on dead Qt modules (e.g. QtScript, it has it's own (outdated?) QML 
parser fork). Other cool build systems (e.g. gradle) download half of the 
internet before they start, so, a build system that depends on a library like 
Qt is not that bad. As I said it has huge potential and in the future Qt will 
help to implement cool features like: automatically download/clone/checkout 
3rd partly libs, etc.

- QBS was introduced to us as a build system designed with tooling in mind, 
sadly that crucial aspect was forgotten (the above bugs prove what I'm 
saying).

- QBS developers don't use it in large projects with lots of dependencies, 
with situations when you need to build & run tools to generate code, when you 
need to build and/or run tools to check dependencies, when you need to test 
compiler flags, etc. (apart from QtCreator which has just a few dependencies). 
You might think that they started to use QBS to compile Qt to test all these 
things, well, think again, that work was started by a brave contributor 
(Andrew Knight) who is not a QBS developer! After the work was started, QBS 
developers jumped in.

- is QBS finished and ready to replace cmake/qmake/gradle/etc.? IMHO no! There 
are not too many remaining features to implement, but if the development 
continues at current speed I'm afraid we'll see people walking on Mars before 
we'll see QBS finished... I hope that trying to build Qt with QBS will motivate 
QBS developers to implement these features faster.


Cheers,
BogDan.

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

Re: [Development] QML: Why C++11 scoped enums are not scoped in QML?

[BogDan Vatra]

On joi, 28 iulie 2016 09:52:56 EEST Dominik Holland wrote:
> Am 28.07.16 um 09:41 schrieb Olivier Goffart:
> > On Donnerstag, 28. Juli 2016 10:32:54 CEST BogDan Vatra wrote:
> >> On miercuri, 27 iulie 2016 09:08:32 EEST Thiago Macieira wrote:
> >>> On quarta-feira, 27 de julho de 2016 11:47:03 PDT BogDan Vatra wrote:
> >>>> On miercuri, 27 iulie 2016 10:35:01 EEST André Somers wrote:
> >>>>> Op 27/07/2016 om 09:53 schreef BogDan Vatra:
> >>>>> Would that not break existing QML applications that now use enums
> >>>>> backed
> >>>>> by scoped enums in C++?
> >>>> 
> >>>> It will, but personaly I can't see a better solution ...
> >>> 
> >>> I have already said what to do: make it an opt-in on registration of the
> >>> enum to the QML/JS engine.
> >> 
> >> Got it  :)
> >> 
> >>>> So, either we break the existing QML apps that used scoped enums in C++
> >>>> (which is useless, because in QML side you'll get name clashing) or we
> >>>> keep
> >>>> it as it is now and never "fix" it. I'd like the first option :).
> >>> 
> >>> I really hate it. Breaking applications should not even be an option on
> >>> the
> >>> table. Let's start with "we won't gratuitously break applications" and
> >>> work
> >>> to find a solution from there.
> >>> 
> >>>> Of course if we can find a better solution to have them both is even
> >>>> better
> >>>> !
> >> 
> >> What I was trying to say here is that I'd like to have by default C++11
> >> scoped enums scoped also on QML, but if everybody thinks is a no go, than
> >> we can co the other way around.
> >> 
> >> Anyway, I checked the code a little bit, hopping it will be a few lines
> >> change, but I was so wrong :). I tried to prefix the (scoped) enum keys
> >> with the "EnumName." but of course it didn't worked :D, "EnumName_"
> >> works fine. It seems it needs much love (probably some virtual types
> >> based on
> >> EnumName), unfortunately my QML engine knowledge are too limited to
> >> continue :).
> > 
> > Note that in C++11, all enums can be used scoped. (even the normal ones)
> > I think it would make sens to allow all enum to be used scoped in QML too.
> 
> Mhh how do you make sure that the Enum names are unique ? E.g. having
> two custom Items and both having a Enum in them called Type, what whould
> you get if you do Type.FOO ?
> 
Nothing, C++11 scoped enums just add one more scope of their existing scope. 
So, if you have:
class Type {
enum class Enum {
  FOO
}
};

In C++ you'll need to use *Type.Enum.FOO* to access it, and we want to have 
the *same thing* in QML :).

[...]

Cheers,
BogDan.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] [QML]: Why can't create Q_GADGETs from QML ?

[BogDan Vatra]

Hi,

Task created here https://bugreports.qt.io/browse/QTBUG-54983

Cheers,
BogDan.

On marți, 26 iulie 2016 15:37:04 EEST Simon Hausmann wrote:
> Hi,
> 
> 
> No objection per-se, but we'd have to figure out some details. For example
> declarative instantiation is
> 
> not an object, as the ownership rules do not comply with QObject. That would
> leave us with a JavaScript
> 
> constructor function, replacing Qt.point(...) for example. But then we'd
> have to comply with the namespace
> 
> rules, so we'd have
> 
> 
> qmlRegisterGadget("MyModule", "ThatName", 1, 0);
> 
> 
> and then
> 
> 
> import MyModule 1.0
> 
> 
> and in expressions we'd have
> 
> 
> var g = new ThatName();
> 
> 
> and the same for a namespaced import:
> 
> 
> import MyModule 1.0 as Foo
> 
> 
> var g = new Foo.ThatName();
> 
> 
> It's a bit of work to do, but I don't see a problem in principle.
> 
> 
> Simon
> 
> 
> From: Development <development-bounces+simon.hausmann=qt...@qt-project.org>
> on behalf of BogDan Vatra <bog...@kdab.com> Sent: Tuesday, July 26, 2016
> 5:28:35 PM
> To: development@qt-project.org
> Subject: [Development] [QML]: Why can't create Q_GADGETs from QML ?
> 
> Hi,
> 
> Is there any reason why I can only use Q_GADGETs objects in QML, but not to
> create them?
> 
> It will be nice if we can register Q_GADGETs  as qml creatable types too.
> 
> Cheers,
> BogDan.
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development


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

Re: [Development] [QML]: Register global enums/flags to QML ?

[BogDan Vatra]

On joi, 28 iulie 2016 09:22:37 EEST Olivier Goffart wrote:
> On Dienstag, 26. Juli 2016 18:18:48 CEST BogDan Vatra wrote:
> > Hello,
> > 
> > I'd like to be able to register some "global" enums/flags to QML. I
> > checked
> > a little bit how Qt does with all the enums from Qt namespace
> > (qnamespace.h) and I end-up in qqmlbuiltinfunctions which does all the
> > "magic" which can't be used by normal developers/libs.
> > 
> > Because I think having "global" enums is a very nice feature, I'd like to
> > know if other people and QML maintainers agree with me :).
> > 
> > If yes, then want to propose the followings:
> >  - add one more Q_OBJECT/Q_GADGET like macro for namespaces
> >  (Q_NAMESPACE?),
> > 
> > which declares the mandatory "extern const QMetaObject staticMetaObject" (
> > or just "extern const QMetaEnum  staticMetaEnum" ? because in principle
> > we'll only be able to declare enums/flags ?) into that namespace. Most
> > probably moc will need some love to properly handle the new Q_magic_macro.
> > If is too much trouble we can use the qnamespace.h hack.
> > 
> >  - add a helper macro/function to register the namespace enums/flags (i.e.
> > 
> > qmlRegisterNamespace or even better qmlRegisterEnums(const QMetaEnum
> > , ).
> > 
> > I think it depends on QML c++11 scoped enums task, because most probably
> > the enums enumerators names will clash.
> 
> Yes, i think a Q_NAMESPACE would be a nice addition in order to allow Q_ENUM
> at namespace scope.   We have some example for example in the QSsl
> namespace that has enumerations.
> 
> One issue is that moc need to have a complete view of the namespace as it
> generates the QMetaObject for it, so it should not be possible to have
> Q_ENUM in a other header than the one which have the Q_NAMESPACE keyword.

Thanks Olivier!

I created two new taks:
 - https://bugreports.qt.io/browse/QTBUG-54981 (moc part)
 - https://bugreports.qt.io/browse/QTBUG-54982 (qml part)

Cheers,
BogDan.

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

Re: [Development] QML: Why C++11 scoped enums are not scoped in QML?

[BogDan Vatra]

On miercuri, 27 iulie 2016 09:08:32 EEST Thiago Macieira wrote:
> On quarta-feira, 27 de julho de 2016 11:47:03 PDT BogDan Vatra wrote:
> > On miercuri, 27 iulie 2016 10:35:01 EEST André Somers wrote:
> > > Op 27/07/2016 om 09:53 schreef BogDan Vatra:
> > > Would that not break existing QML applications that now use enums backed
> > > by scoped enums in C++?
> > 
> > It will, but personaly I can't see a better solution ...
> 
> I have already said what to do: make it an opt-in on registration of the
> enum to the QML/JS engine.
> 

Got it  :)

> > So, either we break the existing QML apps that used scoped enums in C++
> > (which is useless, because in QML side you'll get name clashing) or we
> > keep
> > it as it is now and never "fix" it. I'd like the first option :).
> 
> I really hate it. Breaking applications should not even be an option on the
> table. Let's start with "we won't gratuitously break applications" and work
> to find a solution from there.
> 
> > Of course if we can find a better solution to have them both is even
> > better
> > !

What I was trying to say here is that I'd like to have by default C++11 scoped 
enums scoped also on QML, but if everybody thinks is a no go, than we can co 
the other way around.

Anyway, I checked the code a little bit, hopping it will be a few lines 
change, but I was so wrong :). I tried to prefix the (scoped) enum keys with 
the "EnumName." but of course it didn't worked :D, "EnumName_" works fine. It 
seems it needs much love (probably some virtual types based on EnumName), 
unfortunately my QML engine knowledge are too limited to continue :).

Cheers,
BogDan.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QML: Why C++11 scoped enums are not scoped in QML?

[BogDan Vatra]

On miercuri, 27 iulie 2016 10:35:01 EEST André Somers wrote:
> Op 27/07/2016 om 09:53 schreef BogDan Vatra:
> >> That said, it would be a behavior change not to allow anymore the
> >> previous
> >> (unscoped) syntax to work with QML
> > 
> > The unscoped enums should work as they are woring now, just the scoped
> > ones
> > should be scoped in QML as well.
> > 
> > Based on your patch, I'll try to prepare a patch for QML.
> 
> Would that not break existing QML applications that now use enums backed
> by scoped enums in C++?
> 

It will, but personaly I can't see a better solution ... 
So, either we break the existing QML apps that used scoped enums in C++ (which 
is useless, because in QML side you'll get name clashing) or we keep it as it 
is now and never "fix" it. I'd like the first option :). 
Of course if we can find a better solution to have them both is even better !

Cheers,
BogDan.

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