Awesome news!
Any ideas/plans for WebAssembly?
On 06.06.19 13:45, 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.
> Since the initial prototype, the port has advanced very
On Thursday, 6 June 2019 09:01:24 PDT Simon Hausmann wrote:
> Apologies, I meant cross compiled to Android arm as well as Linux arm. The
> host system is a regular x86-64 Linux desktop distro. The target sysroot
> and compiler are the ones supplied by the Android SDK/NDK along with the
> cmake tool
I tried that quickly locally by setting set(CMAKE_OSX_ARCHITECTURES
"x86_64;x86_64h" CACHE STRING "")
$file lib/libQt5Core_debug.a
lib/libQt5Core_debug.a: Mach-O universal binary with 2 architectures:
[x86_64:current ar archive] [x86_64h]
lib/libQt5Core_debug.a (for architecture x86_64): c
Hi,
Apologies, I meant cross compiled to Android arm as well as Linux arm. The host
system is a regular x86-64 Linux desktop distro. The target sysroot and
compiler are the ones supplied by the Android SDK/NDK along with the cmake
toolchain file. The embedded Linux case was against a Yocto SDK.
On Thursday, 6 June 2019 07:01:31 PDT Tor Arne Vestbø wrote:
> That’s one step, and will let you create e.g. a fat binary with x86_64 and
> i386, or armv7 and armv8.
Wishlist: compile QtCore and QtGui as a fat binary for x86_64 and x86_64h on
regular macOS.
--
Thiago Macieira - thiago.macieira
On Thursday, 6 June 2019 04:45:14 PDT Simon Hausmann wrote:
> * Builds on
> * Windows (desktop)
> * macOS
> * Linux (desktop and embedded)
> * Android (running not tested yet)
Builds *on* or build *for*? Is someone really trying to compile on Android? Is
this like Aaro
Иван Комиссаров wrote:
> I think, your point is wrong. Despite the fact Qt is a GUI toolkit, it should
> perform well.
> Take a look at Qt Item Views. They really sucks in terms of performance.
> QAbstractItemModel can have any number of rows/columns (that fits in MAX_INT),
> but which view can r
On 6. Jun 2019, at 16:48, Christian Gagneraud
mailto:chg...@gmail.com>> wrote:
On Fri, 7 Jun 2019 at 02:25, Simon Hausmann
mailto:simon.hausm...@qt.io>> wrote:
Am 06.06.19 um 16:17 schrieb Christian Gagneraud:
On Fri, 7 Jun 2019 at 02:08, Simon Hausmann
mailto:simon.hausm...@qt.io>> wrote:
On Thu, 6 Jun 2019 at 23:46, 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.
> Since the initial prototype, the port has advanced very well and its
> current state can be
> Looking at the CMake documentation – it looks like a maze.
I would recommend starting at the cmake-buildsystem doc page which gives a
general overview of the concepts of CMake :
https://cmake.org/cmake/help/v3.15/manual/cmake-buildsystem.7.html
It is also available as a man page for unix users (
On 2019-06-06 15:49, Lars Knoll wrote:
On 6 Jun 2019, at 15:36, Mutz, Marc via Development
wrote:
On 2019-06-06 15:14, Konstantin Tokarev wrote:
[...]
There is a principle of single level of abstraction [1], and inline
implementation
of flat map can be viewed of violation of such principle. I
On Fri, 7 Jun 2019 at 02:25, Simon Hausmann wrote:
>
>
> Am 06.06.19 um 16:17 schrieb Christian Gagneraud:
> > On Fri, 7 Jun 2019 at 02:08, Simon Hausmann wrote:
> >>
> >> Am 06.06.19 um 15:52 schrieb Christian Gagneraud:
> >>> On Fri, 7 Jun 2019 at 01:35, Bogdan Vatra via Development
> >>> wrot
Hi,
I wrote an initial draft for how to port a module from qmake to CMake, and once
more of the internals have been stabilized, I intend to add those as well.
https://wiki.qt.io/CMake_Port/Porting_Guide
Note that many (not all) of the internals are actually well commented inside
the source co
Am 06.06.19 um 16:17 schrieb Christian Gagneraud:
> On Fri, 7 Jun 2019 at 02:08, Simon Hausmann wrote:
>>
>> Am 06.06.19 um 15:52 schrieb Christian Gagneraud:
>>> On Fri, 7 Jun 2019 at 01:35, Bogdan Vatra via Development
>>> wrote:
Hi,
I won't hold my breath for community support
Hello Kavindra,
There is a bug report about improving the Qt CMake documentation, where we are
collecting ideas: https://bugreports.qt.io/browse/QTBUG-72159
Please add your questions and concerns there.
Cheers,
Leena
Date: Thu, 6 Jun 2019 14:08:56 +
From: "Palaraja, Kavindra"
To: "devel
Thanks for the links.
Looking at the CMake documentation – it looks like a maze. So definitely,
content that resembles a “Migration Guide” would be helpful for users.
Especially if there are cases where there’s no 1-1 mapping from qmake --> CMake.
Yes, the exact link to the CMake version would
On Fri, 7 Jun 2019 at 02:08, Simon Hausmann wrote:
>
>
> Am 06.06.19 um 15:52 schrieb Christian Gagneraud:
> > On Fri, 7 Jun 2019 at 01:35, Bogdan Vatra via Development
> > wrote:
> >> Hi,
> >>
> >> I won't hold my breath for community support for iOS. iOS is out for so
> >> many
> >> years, yet
Am 06.06.19 um 16:01 schrieb Tor Arne Vestbø:
>
>> On 6 Jun 2019, at 15:41, Simon Hausmann wrote:
>>
>> Hi,
>>
>> I believe the code signing part is covered by existing CMake xcode support,
>> as it is also for macOS.
>>
>> The support for fat binaries is something I don't have hands-on experien
That's good to hear. I understand that there will be two levels of
documentation:
- CMake itself on their side
- Qt's CMake related content; like the macros you mention
Regarding the possibly-internal bits, I would vote for having them documented
still -- even if there's a note or a disclaimer
Am 06.06.19 um 15:52 schrieb Christian Gagneraud:
> On Fri, 7 Jun 2019 at 01:35, Bogdan Vatra via Development
> wrote:
>> 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 yo
> On 6 Jun 2019, at 15:45, Lars Knoll wrote:
>
>
>
>> On 6 Jun 2019, at 15:33, Иван Комиссаров wrote:
>>
>> Sorry, but the iOS should be properly supported before making the final
>> decision.
>> Building something on macOS is easy, building smth for iOS is harder. From
>> the top of my h
06.06.2019, 17:01, "Lars Knoll" :
>> On 6 Jun 2019, at 15:33, Иван Комиссаров wrote:
>>
>> Sorry, but the iOS should be properly supported before making the final
>> decision.
>> Building something on macOS is easy, building smth for iOS is harder. From
>> the top of my head it is code signing
Hi,
I think our users should eventually end up in area that is currently called the
"CMake Manual" in the docs. For example through one of the various overviews.
As far as I can tell that page is currently located at
https://doc.qt.io/qt-5/cmake-manual.html
That page targets application d
> On 6 Jun 2019, at 15:41, Simon Hausmann wrote:
>
> Hi,
>
> I believe the code signing part is covered by existing CMake xcode support,
> as it is also for macOS.
>
> The support for fat binaries is something I don't have hands-on experience,
> but the upstream documentation suggests suppo
> -Original Message-
> From: Development On Behalf Of
> Palaraja, Kavindra
> Sent: Thursday, June 6, 2019 3:38 PM
> To: development@qt-project.org
> Subject: Re: [Development] Proposing CMake as build tool for Qt 6
>
> Hi,
>
> Just curious, do you have a link to what the draft document
It was partially supported for iOS actually. I was working on that front to
make it work properly when building qtbase, and there are still WIP patches for
that, but it wasn't completely finished.
But yes, in principle qbs is the only other modern build tool that i know that
could do that. Excl
On Fri, 7 Jun 2019 at 01:35, Bogdan Vatra via Development
wrote:
>
> 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 cmak
> On 6 Jun 2019, at 15:36, Mutz, Marc via Development
> wrote:
>
> On 2019-06-06 15:14, Konstantin Tokarev wrote:
> [...]
>> There is a principle of single level of abstraction [1], and inline
>> implementation
>> of flat map can be viewed of violation of such principle. If flat map
>> implement
On 6 Jun 2019, at 15:33, Иван Комиссаров
mailto:abba...@gmail.com>> wrote:
Sorry, but the iOS should be properly supported before making the final
decision.
Building something on macOS is easy, building smth for iOS is harder. From the
top of my head it is code signing and building "fat" bina
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,
I believe the code signing part is covered by existing CMake xcode support, as
it is also for macOS.
The support for fat binaries is something I don't have hands-on experience, but
the upstream documentation suggests support for it on macOS, iOS, etc.:
https://cmake.org/cmake/help/late
Hi,
Your statement that CMake has no support for iOS is incorrect. From
https://cmake.org/cmake/help/v3.14/release/3.14.html#platforms :
* CMake now supports Cross Compiling for iOS, tvOS, or watchOS using simple
toolchain files.
It is also my understanding that projects using CMake can us
Hi,
Just curious, do you have a link to what the draft documentation for CMake
looks like?
qmake's documentation has always been an afterthought. The documentation
equivalent for CMake should be better than that – at the very least, it
shouldn’t result in another https://wiki.qt.io/Undocumente
On 2019-06-06 15:14, Konstantin Tokarev wrote:
[...]
There is a principle of single level of abstraction [1], and inline
implementation
of flat map can be viewed of violation of such principle. If flat map
implementations
were kept speparately, it would indeed make code easier to read and
mainta
Sorry, but the iOS should be properly supported before making the final
decision.
Building something on macOS is easy, building smth for iOS is harder. From the
top of my head it is code signing and building "fat" binaries that should be
tested as a proof of concept.
Иван Комиссаров
> 6 июня 2
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 i
06.06.2019, 16:25, "Simon Hausmann" :
> 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.
Yet another alt
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
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
06.06.2019, 15:43, "Elvis Stansvik" :
> Den tors 6 juni 2019 kl 13:56 skrev Elvis Stansvik :
>> Den tors 6 juni 2019 kl 13:40 skrev Mutz, Marc via Development
>> :
>> >
>> > On 2019-06-06 12:24, Lars Knoll wrote:
>> > >> On 6 Jun 2019, at 11:08, Simon Hausmann
>> > >> 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
> cu
> On 6 Jun 2019, at 14:49, Mutz, Marc via Development
> wrote:
>
> On 2019-06-06 14:04, Lars Knoll wrote:
>>> On 6 Jun 2019, at 13:39, Mutz, Marc via Development
>>> wrote:
> [...]
>>> You are equating Qt users and Qt implementers. You can maintain the Qt API,
>>> but use more efficient data
On 2019-06-06 14:04, Lars Knoll wrote:
On 6 Jun 2019, at 13:39, Mutz, Marc via Development
wrote:
[...]
You are equating Qt users and Qt implementers. You can maintain the Qt
API, but use more efficient data structures in the implementation. You
seem to be implying that these two things canno
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
Den tors 6 juni 2019 kl 13:56 skrev Elvis Stansvik :
>
> Den tors 6 juni 2019 kl 13:40 skrev Mutz, Marc via Development
> :
> >
> > On 2019-06-06 12:24, Lars Knoll wrote:
> > >> On 6 Jun 2019, at 11:08, Simon Hausmann
> > >> wrote:
> > >>
> > >> Am 06.06.19 um 10:42 schrieb Mutz, Marc via Developm
On Thu, 06 Jun 2019 13:46:12 +0200
"Mutz, Marc via Development" wrote:
> On 2019-06-06 12:24, Ola Røer Thorsen wrote:
> > tor. 6. jun. 2019 kl. 10:21 skrev Vitaly Fanaskov
> > :
> >
> >> Qt is GUI framework. Not only, yes, but this is the main purpose.
> >> +/-
> >> 10MB is almost nothing for GU
> On 6 Jun 2019, at 13:39, Mutz, Marc via Development
> wrote:
>
> On 2019-06-06 12:24, Lars Knoll wrote:
>>> On 6 Jun 2019, at 11:08, Simon Hausmann
>>> wrote:
>>> Am 06.06.19 um 10:42 schrieb Mutz, Marc via Development:
> [...]
I have the feeling that some participants of these discussio
Den tors 6 juni 2019 kl 13:40 skrev Mutz, Marc via Development
:
>
> On 2019-06-06 12:24, Lars Knoll wrote:
> >> On 6 Jun 2019, at 11:08, Simon Hausmann
> >> wrote:
> >>
> >> Am 06.06.19 um 10:42 schrieb Mutz, Marc via Development:
> [...]
> >>> I have the feeling that some participants of these d
On 2019-06-06 12:24, Ola Røer Thorsen wrote:
tor. 6. jun. 2019 kl. 10:21 skrev Vitaly Fanaskov
:
Qt is GUI framework. Not only, yes, but this is the main purpose.
+/-
10MB is almost nothing for GUI apps. Slightly faster
lookup/insertions,
cache line, proper alignment... Well, nice to have, but
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 (d
On 2019-06-06 12:24, Lars Knoll wrote:
On 6 Jun 2019, at 11:08, Simon Hausmann
wrote:
Am 06.06.19 um 10:42 schrieb Mutz, Marc via Development:
[...]
I have the feeling that some participants of these discussions
thought
they joined an adulation club for Qt API lovers instead.
I don't quite
tor. 6. jun. 2019 kl. 10:21 skrev Vitaly Fanaskov :
> Qt is GUI framework. Not only, yes, but this is the main purpose. +/-
> 10MB is almost nothing for GUI apps. Slightly faster lookup/insertions,
> cache line, proper alignment... Well, nice to have, but when an app
> spends most of the time on r
On 6 Jun 2019, at 11:08, Simon Hausmann
mailto:simon.hausm...@qt.io>> wrote:
Am 06.06.19 um 10:42 schrieb Mutz, Marc via Development:
On 2019-06-06 09:47, Simon Hausmann wrote:
[...]
However I don't find your arguments that find_if/lower_bound is not
harder to read convincing. I continue to ag
On 6 Jun 2019, at 10:42, Mutz, Marc via Development
wrote:
>
> *But* it's not "hard to read" in the sense that you stare at it and can't
> figure out what the hell the code is doing.
You can insult my intelligence and CS credentials all you want, I’m still going
to claim that the STL-code in
>> Thanks, Ivan. While this is true for other libs like xcb, Qt does not ship
>> icu. It uses either the one provided by the system or a thin replacement
>> resulting in a reduced localization feature set according to
>> https://wiki.qt.io/Qt_5_ICU#Design_Principles
>
> Linux binaries are shipped
On 2019-06-06 11:08, Simon Hausmann wrote:
Am 06.06.19 um 10:42 schrieb Mutz, Marc via Development:
[...]
Do you guys _actually_ think that readability of Qt code trumps
_everything_?
For me the answer is "no". I believe that for the majority of Qt code
we
should strike for a compromise -
06.06.2019, 11:12, "Richard Weickelt" :
> On 05.06.2019 21:28, Иван Комиссаров wrote:
>> AFAIK -R . is used to load that icu libraries I told you about in Gerrit.
>>
>> Otherwise it will try to load the system ones instead of the shipped ones
>> with Qt.
>
> Thanks, Ivan. While this is true fo
Well, my point was: there always should be a trade off. I've never wrote
that Qt should be slow. I just wanted to point out that understanding of
performance might be different for different sort of libraries (and for
different cases).
I hope, you filed a ticket or fixed this problem yourself.
Hi Marc,
I agree with a lot of your points. Performance is important to me. I won't get
bogged down in the specifics, because way too much energy has already been
wasted on this (and related) threads I think, so I'll just say a few things.
On Thu, Jun 6, 2019, at 10:45 AM, Mutz, Marc via Develo
I think, your point is wrong. Despite the fact Qt is a GUI toolkit, it should
perform well.
Take a look at Qt Item Views. They really sucks in terms of performance.
QAbstractItemModel can have any number of rows/columns (that fits in MAX_INT),
but which view can really handle that? None of them!
Am 06.06.19 um 10:42 schrieb Mutz, Marc via Development:
> On 2019-06-06 09:47, Simon Hausmann wrote:
> [...]
>> However I don't find your arguments that find_if/lower_bound is not
>> harder to read convincing. I continue to agree with Joerg and Tor Arne
>> and feel that the API of the associative
On 2019-06-06 10:17, Vitaly Fanaskov wrote:
As a library implementer, you are simply not _allowed_ the freedom to
use a convenient tool over the most efficient one. That is, to put it
mildly, a disservice to users and a disgrace to the profession of
programmers.
Well, optimization is probably go
On 2019-06-06 09:47, Simon Hausmann wrote:
[...]
However I don't find your arguments that find_if/lower_bound is not
harder to read convincing. I continue to agree with Joerg and Tor Arne
and feel that the API of the associative containers results in code
that
is more compact, visually less noi
> As a library implementer, you are simply not _allowed_ the freedom to
> use a convenient tool over the most efficient one. That is, to put it
> mildly, a disservice to users and a disgrace to the profession of
> programmers.
Well, optimization is probably good, but not always, I would say. If
yo
Hi,
On Linux/macOS the current directory is not automatically/always an path where
the dynamic linker searches implicitly for dependencies. That's only Windows :)
Simon
From: Development on behalf of Richard
Weickelt
Sent: Thursday, June 6, 2019 10:10
To: Ива
On 05.06.2019 21:28, Иван Комиссаров wrote:
> AFAIK -R . is used to load that icu libraries I told you about in Gerrit.
>
> Otherwise it will try to load the system ones instead of the shipped ones
> with Qt.
Thanks, Ivan. While this is true for other libs like xcb, Qt does not ship
icu. It uses
I second your use of sorted vectors, especially for small ones.
However, a key to master code complexity is to be able to easily recognize
abstractions.
This reduces cognitive load when dealing with code. Generally Qt shines here.
A potential QDictionnary would speak to a reader more directly th
Am 06.06.19 um 09:05 schrieb Mutz, Marc via Development:
> On 2019-06-06 08:24, Joerg Bornemann wrote:
>> On 6/5/19 5:49 PM, Mutz, Marc via Development wrote:
>>
>>> As a library implementer, you are simply not _allowed_ the freedom to
>>> use a convenient tool over the most efficient one. That is
> The "mixed signal" here is that someone in an ivory tower decided to
> deprecate something but was not able to offer a viable alternative.
>
> Either because there simply was none (in which case the deprecation was
> wrong, and should be undone) or because the work-around was too much hassle
>
On 2019-06-06 08:24, Joerg Bornemann wrote:
On 6/5/19 5:49 PM, Mutz, Marc via Development wrote:
As a library implementer, you are simply not _allowed_ the freedom to
use a convenient tool over the most efficient one. That is, to put it
mildly, a disservice to users and a disgrace to the profes
70 matches
Mail list logo
