[Development] HEADS-UP: Qt 5.14.0 Feature Freeze is getting closer

[Jani Heikkinen]

Hi,

Just a kindly reminder: Qt 5.14.0 Feature Freeze will be in effect 26th August 
2019, see https://wiki.qt.io/Qt_5.14_Release

All new modules must be in qt5.git#dev before soft branching starts 
(19.08.2019). So please start add those in dev as soon as possible. And please 
remember to inform release team (qt.team.relea...@qt.io) about any new 
submodule; we need to create packaging configurations etc for those as well.

Please also notify us any status changes of existing submodules (TP to 
officially supported, officially supported to deprecated, deprecated to dropped 
etc).

And please start filling new features page as well here: 
https://wiki.qt.io/New_Features_in_Qt_5.14

br,
Jani Heikkinen
Release Manager
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

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

[Thiago Macieira]

On Monday, 17 June 2019 18:43:51 PDT Christian Gagneraud wrote:
> Please elaborate:https://gcc.gnu.org/install/configure.html
> 
> Just from the top of the document:
> --with-pkgversion
> --with-bugurl
> ...
> --enable-shared
> --enable-multiarch
> ...
> 
> Your argumentation is ill-formed.

You're describing the theory. That's how it should be.

Kevin is arguing the practice. Let's take nginx:
--with-threads
--with-ipv6
--with-debug
--with-file-aio
--with-http_ssl_module
--with-http_v2_module
--with-poll_module
--with-select_module
--with-stream=dynamic
--with-stream_ssl_module

Maybe some of the modules are external dependencies, but it doesn't look like 
it. Threads, IPv6 definitely are just features. Debugging is usually just a 
build option.

See more at
https://src.fedoraproject.org/rpms/nginx/blob/master/f/nginx.spec#_191

Example of the other way around: COGL, which has:
--enable-gles2=yes
--enable-glx=yes
--enable-gl=yes

All three match libraries. Ditto for EFL, which has --enable-pixman and 
--enable-libvlc to enable the use of an external library.
-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel System Software Products



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

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

[Christian Gagneraud]

On Tue, 18 Jun 2019 at 13:16, Kevin Kofler  wrote:
>
> Christian Gagneraud wrote:
> > with/without tells the system to use a thing or not.
> > enable/disable tells the system to enable/disable the thing feature.
>
> The problem is that typical build options are actually both at the same
> time: using a library enables some feature that depends on the library. So
> the semantic distinction is ill-defined.

Please elaborate:https://gcc.gnu.org/install/configure.html

Just from the top of the document:
--with-pkgversion
--with-bugurl
...
--enable-shared
--enable-multiarch
...

Your argumentation is ill-formed.

Chris

>
> Kevin Kofler
>
> ___
> 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

[Kevin Kofler]

Christian Gagneraud wrote:
> with/without tells the system to use a thing or not.
> enable/disable tells the system to enable/disable the thing feature.

The problem is that typical build options are actually both at the same 
time: using a library enables some feature that depends on the library. So 
the semantic distinction is ill-defined.

Kevin Kofler

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

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

[Christian Gagneraud]

On Tue, 18 Jun 2019 at 11:16, Kevin Kofler  wrote:
>
> Konstantin Tokarev wrote:
> > Autotools provide human-readable options of standardized format
> >
> > --with-thing
> > --without-thing
> > --enable-thing
> > --disable-thing
>
> That's already 2 different standards for essentially the same thing (a
> boolean option),

This doesn't make sense to me, the underlying type has nothing to do
with the intent.

with/without tells the system to use a thing or not.
enable/disable tells the system to enable/disable the thing feature.

eg. --with-pcre --enable-expensive-operations

That is 2 different things even if they can be both expressed as boolean.

> and most non-GNU projects (and even some GNU ones) use them
> pretty arbitrarily and inconsistently. (There is supposed to be a semantic
> difference, but it is often arguable, because often a dependency and a
> feature go together. And several upstreams just use the 2 variants
> interchangeably altogether.)

And so what? Now you're gonna tell us that using CMake makes you smarter?
By switching to CMake you won't do the mistakes you did with another
build system?

With CMake i can arbitrarily and inconsistently use any convention.

>
> In CMake, there's just:
> -DTHING:BOOL=ON
> -DTHING:BOOL=OFF
> (and it also happily accepts a bunch of other notations for ON/OFF, without
> the CMakeLists.txt having to do anything).

So:
-DWITH_THING:BOOL=ON
-DWITH_THING:BOOL=OFF
-DENABLE_THING:BOOL=ON
-DENABLE_THING:BOOL=OFF

No difference except it's not very friendly to type.

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

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

[Kevin Kofler]

Konstantin Tokarev wrote:
> Autotools provide human-readable options of standardized format
> 
> --with-thing
> --without-thing
> --enable-thing
> --disable-thing

That's already 2 different standards for essentially the same thing (a 
boolean option), and most non-GNU projects (and even some GNU ones) use them 
pretty arbitrarily and inconsistently. (There is supposed to be a semantic 
difference, but it is often arguable, because often a dependency and a 
feature go together. And several upstreams just use the 2 variants 
interchangeably altogether.)

In CMake, there's just:
-DTHING:BOOL=ON
-DTHING:BOOL=OFF
(and it also happily accepts a bunch of other notations for ON/OFF, without 
the CMakeLists.txt having to do anything).

Kevin Kofler

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

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

[Thiago Macieira]

On Monday, 17 June 2019 09:03:12 PDT Bogdan Vatra via Development wrote:
> 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.

Agreed. That's why I posted the list of requests that I did.

The difference between searching on StackOverflow or even already knowing how 
to do something, versus debugging the buildsystem tool to figure out why it 
didn't what you expected it to do. My issue wasn't feature-completeness or 
even UX, but community and experience.

If you remember the discussion from back then, I explained that it was 
libvpx's buildsystem that prompted me. It's a manually-written Makefile (no 
generator) that runs $(MAKE) on itself after detecting some things and setting 
make variables.

And I'm not saying you can't shoot yourself with CMake either. There are 
several Intel-created projects using CMake that prove that point quite easily. 
But even those it's not very difficult for me to point them to well-written 
CMakeLists.txt using GNUInstallDirs.cmake that they can just adopt & adapt, 
ditching their well-meaning but ill-advised hand-rolled solutions.

THAT is what I need.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel System Software Products



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

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

[Thiago Macieira]

On Monday, 17 June 2019 08:56:15 PDT Konstantin Tokarev wrote:
> > 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 

No one is proposing blindly using stuff from random GitHub repositories. We're 
not Node.js.

Reusing existing code is not blindly trusting. It would imply importing the 
feature, inspecting it and integrating with our build. It's a means to speed 
up development, by reusing prior work with pride. In the spirit of Open 
Source.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel System Software Products



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

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

[Matthew Woehlke]

On 17/06/2019 12.08, Bogdan Vatra via Development wrote:
> Or use a buildsystem that doesn't take to the hell?

Real world experience has shown that there is no such thing.

As much as people like to bitch about how "convoluted" CMake is, CMake
doesn't just set out to be obtuse. That complexity exists for a reason.

Any build system that claims to eliminate that complexity *will* fail.
Either it will end up growing that complexity *anyway*, because it *has*
to, or it will only work in a small subset of possible environments.

The difference between QBS and CMake is like the difference between a
bright-eyed recruit just out of school and a grizzled veteran. Do you
want the one that looks pretty and knows the *theory* (however
advanced), but gets confused when the real world doesn't conform to his
classroom expectations, or the one that looks worn but has the
*experience* and knows how to get things done?

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

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

[Konstantin Tokarev]

17.06.2019, 19:09, "Konstantin Tokarev" :
> 17.06.2019, 18:43, "Thiago Macieira" :
>>  On Monday, 17 June 2019 08:16:38 PDT Konstantin Tokarev wrote:
>>>   17.06.2019, 18:15, "Thiago Macieira" :
>>>   > On Monday, 17 June 2019 02:52:03 PDT Konstantin Tokarev wrote:
>>>   >> I think that automatic generation of PCH is a bad idea, leading to
>>>   >> wasting
>>>   >> build time.
>>>   >
>>>   > Like we do in Qt today?
>>>
>>>   Yep. Approach of Qt Creator is much better.
>>
>>  Elaborate, please.
>
> Qt Creator uses manually crafted precompiled header files [1,2], which include
> only those headers which are often used across the project. If you pull all 
> public
> headers of used Qt modules into pch like it was a kitchen sink, you spend a 
> lot of
> extra time precompiling stuff which wiould be used once or twice. It also 
> increases
> size of binary representation of PCH, and might make compilation slower 
> because
> compiler now has to do lookups in larger AST.
>
> [1] 
> https://code.qt.io/cgit/qt-creator/qt-creator.git/tree/src/shared/qtcreator_pch.h
> [2] 
> https://code.qt.io/cgit/qt-creator/qt-creator.git/tree/src/shared/qtcreator_gui_pch.h

To put it differently:

Including some header into PCH is an optimization. Including everything into 
PCH without
proof that each header there is necessary is premature optimization.

-- 
Regards,
Konstantin

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

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

[Konstantin Tokarev]

17.06.2019, 19:08, "Bogdan Vatra" :
> [...]
>>  >
>>  > [...]
>>  >
>>  > 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?

For that matter, qmake isn't much better when you need to do something that
it doesn't support out of the box. While cmake is like a sledge hammer, and
if you can't achieve something gracefully you can use its sheer brute force,
qmake is more like a magic book which often requires a help of more 
experienced wizard in order to use it.

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

-- 
Regards,
Konstantin

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

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

[Konstantin Tokarev]

17.06.2019, 19:08, "Bogdan Vatra" :
> [...]
>>  >
>>  > [...]
>>  >
>>  > 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?

It's extensible in a way that it's possible to have custom package formats 
while using
shared package specification for all kinds of packages.

>   With so much support our there you should find if CPack can do all the steps
> to build an Android package in seconds, right?

I hve no experience in developing for Android. Quick Google search shows some
scripts like [1] calling androiddeployqt inside.

[1] 
https://salsa.debian.org/debian/openorienteering-mapper/blob/0bb07470365b9b287da649bb9eb8ae4be02da18a/android/CPackConfig.cmake.in

-- 
Regards,
Konstantin

___
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

[Konstantin Tokarev]

17.06.2019, 18:43, "Thiago Macieira" :
> On Monday, 17 June 2019 08:16:38 PDT Konstantin Tokarev wrote:
>>  17.06.2019, 18:15, "Thiago Macieira" :
>>  > On Monday, 17 June 2019 02:52:03 PDT Konstantin Tokarev wrote:
>>  >> I think that automatic generation of PCH is a bad idea, leading to
>>  >> wasting
>>  >> build time.
>>  >
>>  > Like we do in Qt today?
>>
>>  Yep. Approach of Qt Creator is much better.
>
> Elaborate, please.

Qt Creator uses manually crafted precompiled header files [1,2], which include
only those headers which are often used across the project. If you pull all 
public
headers of used Qt modules into pch like it was a kitchen sink, you spend a lot 
of
extra time precompiling stuff which wiould be used once or twice. It also 
increases
size of binary representation of PCH, and might make compilation slower because
compiler now has to do lookups in larger AST.

[1] 
https://code.qt.io/cgit/qt-creator/qt-creator.git/tree/src/shared/qtcreator_pch.h
[2] 
https://code.qt.io/cgit/qt-creator/qt-creator.git/tree/src/shared/qtcreator_gui_pch.h



-- 
Regards,
Konstantin

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

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

[Kyle Edwards]

On Mon, 2019-06-17 at 11:45 -0400, Matthew Woehlke wrote:
> Building both shared and static in a single tree with CMake is
> perfectly
> do-able. See e.g. LCM, which does so. (The main caveat is that they
> need
> different target names.)

And both targets have to have their OUTPUT_NAME property set to the
same value (you don't want libfoo_static.a and libfoo_shared.so.)

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

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

[Konstantin Tokarev]

17.06.2019, 18:51, "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 ?!?!?

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

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

-- 
Regards,
Konstantin

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

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

[Matthew Woehlke]

On 15/06/2019 15.22, Bogdan Vatra via Development wrote:
>  - no multi ABIs builds in one go (needed for msvc and useful also for 
> Android). 
...but MSVC has *never* built multiple ABI's in one go.

OTOH, MSVC is a multi-config generator and *does* support multiple ABI's
in a single build tree.

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

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

[Matthew Woehlke]

On 15/06/2019 12.32, Thiago Macieira wrote:
> On Friday, 14 June 2019 23:45:47 PDT Bogdan Vatra via Development wrote:
>>> 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.
> 
> I meant "shared-and-static".

Building both shared and static in a single tree with CMake is perfectly
do-able. See e.g. LCM, which does so. (The main caveat is that they need
different target names.)

-- 
Matthew
___
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

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

[Konstantin Tokarev]

17.06.2019, 18:17, "Matthew Woehlke" :
> On 17/06/2019 08.44, Konstantin Tokarev wrote:
>>  Also, are you trying to say that cmake's configuration system is
>>  more user friendly than Qt's configure
>
> Yes. Very much so.
>
>>  (or for, that matter, autotool's configure or similar things in sane
>>  build systems)?
>
> Yes. Very much so.

then our definitions of friendliness vary. I'd rather call cmake's behvior
user-hostile.

>
>>  All of the latter provide a set of documented options with
>>  human-oriented names,
>
> CMake's options are also documented. (Or, at least, they should be. If
> they aren't, that's the fault of the project author(s), though, not
> CMake. Similarly, I'm sure you can neglect to document autotools options.)

In ccmake there is only one line per option for documentation. And I can't find
documentation in cmake-gui either.

>
> The difference is that autotools just spits out a great block of text at
> me. With ccmake / cmake-gui, I can *interactively* putter around the
> available options. And I don't have to copy/paste to turn things on, or
> worry if I need to remember to run configure with the same arguments
> every time, or...

This approach gives you no way to extract your actualy configuration line after
you finished your interactive configuration. That's why everyone uses commands
like

 cmake -DX=A -DY=B -DZ=C ...

in their build instructions (though variable names are much less pleasant, in
particular to prevent name conflicts with cmake builtins and 3rd-party projects)

>
>>  [...] which exposes internal variable names as they are.
>
> Again, poor naming is not CMake's fault. I'm sure you can give autotools
> config options very poor names also.

Autotools provide human-readable options of standardized format

--with-thing
--without-thing
--enable-thing
--disable-thing

Also there are a lot of standard options working with any project, like --host=
which provides cross-compilation

>
> Having recently tried to build Qt myself for the first time, I very,
> very much miss having something like ccmake...

As much as I miss really helpful --help with cmake

-- 
Regards,
Konstantin

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

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

[Thiago Macieira]

On Monday, 17 June 2019 08:16:38 PDT Konstantin Tokarev wrote:
> 17.06.2019, 18:15, "Thiago Macieira" :
> > On Monday, 17 June 2019 02:52:03 PDT Konstantin Tokarev wrote:
> >>  I think that automatic generation of PCH is a bad idea, leading to
> >> wasting
> >>  build time.
> > 
> > Like we do in Qt today?
> 
> Yep. Approach of Qt Creator is much better.

Elaborate, please.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel System Software Products



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

Re: [Development] unique_ptr and Qt, Take 2

[Matthew Woehlke]

On 15/06/2019 14.24, Ville Voutilainen wrote:
> On Sat, 15 Jun 2019 at 02:30, Matthew Woehlke  
> wrote:
 OTOH, I just realized a problem with that... when the new child needs to
 take its parent in the ctor for other reasons. I don't know if there is
 an easy solution to that. (Of course, you can still pass the parent with
 createChild, but then you've violated DRY.)
>>>
>>> That seems like a fairly minor problem. We either just pass the
>>> parent in, or make createChild do the child construction with the
>>> parent as an argument if that's valid, or fall back to reparenting if
>>> not.
>>
>> I don't think createChild can/should assume that a QObject* ctor
>> parameter means "parent", i.e. it should *always* explicitly reparent.
> 
> We should perhaps look at whether it could assume it. Or add overloads
> that do/don't.

Overloads could work.

I think assuming could be dangerous in the face of user types, but OTOH
maybe we should make it part of the API that if you have such types, you
are expected to provide a template specialization for your type that
Does The Right Thing.

The more I think about it, the more I suspect that's just the right
solution... make it work for Qt's own classes and user classes that
strictly follow "the rules", and just tell people to specialize it (or
just don't use it) otherwise, rather than trying to overengineer things.

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

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

[Thiago Macieira]

On Monday, 17 June 2019 00:04:10 PDT Joerg Bornemann wrote:
> This will break every user project that's build in debug mode with
> Visual Studio's toolchain (whichever currently available build tool you
> use), because it builds by default with /MDd and will be incompatible
> with Qt. I fear we have to accept what this environment forces upon us.

Fair enough.

I guess those few who want unoptimised /MD builds with debug symbols will 
still use -DCMAKE_BUILD_TYPE=Release and change the flags.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel System Software Products



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

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

[Thiago Macieira]

On Monday, 17 June 2019 01:51:37 PDT Konstantin Tokarev wrote:
> 15.06.2019, 05:29, "Thiago Macieira" :
> > I wonder if Assistant as a standalone application still makes sense.
> 
> Do we have another standalone qch viewer application?

That's assistant. But do we need a standalone qch viewer application?

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel System Software Products



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

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

[Thiago Macieira]

On Monday, 17 June 2019 06:30:50 PDT Jean-Michaël Celerier wrote:
> No problem 
> 
> 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.

That's just because we don't have to discuss plain (non-IDE) editors.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel System Software Products



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

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

[Matthew Woehlke]

On 17/06/2019 08.44, Konstantin Tokarev wrote:
> Also, are you trying to say that cmake's configuration system is
> more user friendly than Qt's configure

Yes. Very much so.

> (or for, that matter, autotool's configure or similar things in sane
> build systems)?
Yes. Very much so.

> All of the latter provide a set of documented options with
> human-oriented names,

CMake's options are also documented. (Or, at least, they should be. If
they aren't, that's the fault of the project author(s), though, not
CMake. Similarly, I'm sure you can neglect to document autotools options.)

The difference is that autotools just spits out a great block of text at
me. With ccmake / cmake-gui, I can *interactively* putter around the
available options. And I don't have to copy/paste to turn things on, or
worry if I need to remember to run configure with the same arguments
every time, or...

> [...] which exposes internal variable names as they are.

Again, poor naming is not CMake's fault. I'm sure you can give autotools
config options very poor names also.

Having recently tried to build Qt myself for the first time, I very,
very much miss having something like ccmake...

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

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

[Konstantin Tokarev]

17.06.2019, 18:15, "Thiago Macieira" :
> On Monday, 17 June 2019 02:52:03 PDT Konstantin Tokarev wrote:
>>  I think that automatic generation of PCH is a bad idea, leading to wasting
>>  build time.
>
> Like we do in Qt today?

Yep. Approach of Qt Creator is much better.

-- 
Regards,
Konstantin

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

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

[Thiago Macieira]

On Monday, 17 June 2019 01:14:50 PDT Elvis Stansvik wrote:
> Hm, what is the problem with using the official CMake binaries? Isn't
> that what you'd do on Windows / macOS anyway?

No. On macOS, you'd use Homebrew. That means it's "distro-packaged" too.

On Windows, I don't know. I'd personally continue to use msys2, which means I 
am also getting a package.

> If distro X (e.g. *buntu 20.04) happen to ship a sufficient version
> when it arrives, then great. But having to install the build tool from
> the vendor instead of the distro package manager surely can't be a
> blocker?

It is, on Linux. Going outside of your distribution methods means you're not 
getting updates. CMake is probably not high-risk software component, but I'd 
rather not have to remember I built an outside copy. That's different from Qt 
itself, since I am *developing* Qt. I have no interest in developing CMake. Or 
PCRE2. Or libjpeg and libpng, which *are* high-risk security vectors.

So, yes, we should strive to ensure the distro-supplied SW is sufficient to 
build Qt. Exceptions are possible, but they need to be justified, like we did 
for PCRE when we began using it in 5.0.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel System Software Products



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

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

[Thiago Macieira]

On Monday, 17 June 2019 02:52:03 PDT Konstantin Tokarev wrote:
> I think that automatic generation of PCH is a bad idea, leading to wasting
> build time.

Like we do in Qt today?

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel System Software Products



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

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

[Alexandru Croitor]

> On 17. Jun 2019, at 15:22, Jean-Michaël Celerier 
>  wrote:
> 
> How do other build systems solve this ? qmake uses mkspecs, qbs uses qbs 
> modules, meson uses a cross-build file... 
> What happens when I want to cross-compile for a new, unknown target with 
> qmake or QBS on Ubuntu ? 
> How can I add features to them if they don't currently support them - e.g., a 
> target to generate doxygen files, or to call gcov & generate a coverage 
> report, or whatever new-fangled way to run link-time optimizations -, without 
> patching them, and without adding stuff to my project source tree ? I don't 
> see how the solution can be fundamentally different from CMake's - except 
> that CMake has a large library of scripts contributed by people out there

One nice thing for users of qmake (which is also a con for other reasons), is 
that when it is built, it has the toolchain info built in.
Whereas with CMake you will always have to specify a 
-DCMAKE_TOOLCHAIN_FILE=very_long_path_here.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

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

[Jean-Michaël Celerier]

No problem :)

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.

Best,
Jean-Michaël



On Mon, Jun 17, 2019 at 3:12 PM Christian Gagneraud 
wrote:

> On Tue, 18 Jun 2019 at 00:27, Christian Gagneraud 
> wrote:
> >
> > On Mon, 17 Jun 2019 at 23:06, Jean-Michaël Celerier
> >  wrote:
> > >
> > > > The world is not spinning around Qt, sorry for the bad news.
> > >
> > > On that we agree : https://www.jetbrains.com/lp/devecosystem-2019/cpp/
> > > I mean, I had actual CMake classes with a CMake exam on paper 6 years
> ago at the university -- you get a few hundreds of new devs on the job
> market every year out of that one, who *will* know CMake, and won't know
> qmake / qbs / [...].
> >
> > Are you insulting this mailing list?
> > How do you think we made it so far without cmake? Honestly?
> >
> > The very fact you're discussing qmake and qbs just show that you know
> > about them, and that you know what they provide cmake cannot provide
> > (yet).
> >
> > > > I prefer a transparent self-bootstrapped Qt over an explicit two
> stages one.
> > > I (entirely personnally) really do not, - this is anecdotally one of
> the main objections I've heard about Qt (3k questions just about Qt's
> configure in SO ! https://stackoverflow.com/search?q=%5Bqt%5D+configure)
> : not just answering to a standard cmake && make && make install which
> comes with gui discoverability through cmake-gui, embeddability through
> add_subdirectory or C++ package managers such as conan, vcpkg, hunter, etc
> etc. but instead acting like its own microcosm library where you have to
> learn yet another set of commands & invocations if you want to integrate it
> in your existing system.
> >
> > Woah, you're ass is so shinny i can't see the light.
>
> Hi Jean-Michaël,
> I would like to apologise about that one, frustration got me in.
> That wasn't smart from me, I do respect everyone, even when I disagree
> with them.
> I didn't mean to insult you, please forgive me, that was a stupid
> behaviour.
>
> Chris
>
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

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

[Jean-Michaël Celerier]

> Are you insulting this mailing list?
How do you think we made it so far without cmake? Honestly?

No, and I apologize if my wording was so poor as to make you think that
this was the goal. I am just trying to point out that there are more people
who learn & know CMake than people who learn qmake or QBS, and that is in
my opinion the n°1 concern when designing something with as large-reaching
goals as Qt's : how is it possible to ensure that most people can use it
right from the get go, without having to learn another additional language.
Basically, how do you reach the next N million of programmers ?

> The very fact you're discussing qmake and qbs just show that you know
about them, and that you know what they provide cmake cannot provide
(yet).

My personal experience with qmake has been that I have migrated most of my
projects from it to CMake around cmake 3.2 and did not look back (but oh
boy am I in pain whenever I have to work on a qmake project with > 15
files).
With QBS, it has been mainly of reporting build errors when using it with
openFrameworks and eventually reverting back to makefiles because of how
broken it was. But this was two years or so ago, though the taste it left
in my mouth (especially after promising so much) was fairly sour.

> Yes, come on, why do i have to define a custom "toolchain file" each
time someone fart?

I really don't see the difference with defining a new mkspec (though I
don't know if you can put mkspecs outside of qt's mkspecs folder ; it would
certainly be nice if it was the case especially when /usr/lib/qt is
readonly).

> Can't you just understand the good old gnu configure triplet? Or the
concept of sytem/user wide profile? (qbs profile, qmake specs)

That's personal preferences, but I really don't like to depend too much on
$distro-provided development packages.
I already wasted waaay enough time in my life investigating why development
package $foo does not work the same on ubuntu 12.04 vs 14.04 vs 16.04 vs
18.04 vs archlinux vs fedora vs freebsd.
I may also have been unlucky but never had I to only switch to another
compiler triplet to make cross-compiling work as I wanted it to.

> Why does every single project has to provide it's own set of CMake
toolchain files?
Have you ever thought about the problem?

How do other build systems solve this ? qmake uses mkspecs, qbs uses qbs
modules, meson uses a cross-build file...
What happens when I want to cross-compile for a new, unknown target with
qmake or QBS on Ubuntu ?
How can I add features to them if they don't currently support them - e.g.,
a target to generate doxygen files, or to call gcov & generate a coverage
report, or whatever new-fangled way to run link-time optimizations -,
without patching them, and without adding stuff to my project source tree ?
I don't see how the solution can be fundamentally different from CMake's -
except that CMake has a large library of scripts contributed by people out
there.

All the best,
Jean-Michaël

On Mon, Jun 17, 2019 at 2:27 PM Christian Gagneraud 
wrote:

> On Mon, 17 Jun 2019 at 23:06, Jean-Michaël Celerier
>  wrote:
> >
> > > The world is not spinning around Qt, sorry for the bad news.
> >
> > On that we agree : https://www.jetbrains.com/lp/devecosystem-2019/cpp/
> > I mean, I had actual CMake classes with a CMake exam on paper 6 years
> ago at the university -- you get a few hundreds of new devs on the job
> market every year out of that one, who *will* know CMake, and won't know
> qmake / qbs / [...].
>
> Are you insulting this mailing list?
> How do you think we made it so far without cmake? Honestly?
>
> The very fact you're discussing qmake and qbs just show that you know
> about them, and that you know what they provide cmake cannot provide
> (yet).
>
> > > I prefer a transparent self-bootstrapped Qt over an explicit two
> stages one.
> > I (entirely personnally) really do not, - this is anecdotally one of the
> main objections I've heard about Qt (3k questions just about Qt's configure
> in SO ! https://stackoverflow.com/search?q=%5Bqt%5D+configure) : not just
> answering to a standard cmake && make && make install which comes with gui
> discoverability through cmake-gui, embeddability through add_subdirectory
> or C++ package managers such as conan, vcpkg, hunter, etc etc. but instead
> acting like its own microcosm library where you have to learn yet another
> set of commands & invocations if you want to integrate it in your existing
> system.
>
> Woah, you're ass is so shinny i can't see the light.
>
> > > Last comment: Please think about [...] Cmake is not yet ready for that.
> >
> > > embedded Linux
> > Oh come on.
>
> Yes, come on, why do i have to define a custom "toolchain file" each
> time someone fart?
> Can't you just understand the good old gnu configure triplet? Or the
> concept of sytem/user wide profile? (qbs profile, qmake specs)
> Why does every single project has to provide it's own set of CMake
> toolchain files?
> Have you ever thought 

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

[Christian Gagneraud]

On Tue, 18 Jun 2019 at 00:27, Christian Gagneraud  wrote:
>
> On Mon, 17 Jun 2019 at 23:06, Jean-Michaël Celerier
>  wrote:
> >
> > > The world is not spinning around Qt, sorry for the bad news.
> >
> > On that we agree : https://www.jetbrains.com/lp/devecosystem-2019/cpp/
> > I mean, I had actual CMake classes with a CMake exam on paper 6 years ago 
> > at the university -- you get a few hundreds of new devs on the job market 
> > every year out of that one, who *will* know CMake, and won't know qmake / 
> > qbs / [...].
>
> Are you insulting this mailing list?
> How do you think we made it so far without cmake? Honestly?
>
> The very fact you're discussing qmake and qbs just show that you know
> about them, and that you know what they provide cmake cannot provide
> (yet).
>
> > > I prefer a transparent self-bootstrapped Qt over an explicit two stages 
> > > one.
> > I (entirely personnally) really do not, - this is anecdotally one of the 
> > main objections I've heard about Qt (3k questions just about Qt's configure 
> > in SO ! https://stackoverflow.com/search?q=%5Bqt%5D+configure) : not just 
> > answering to a standard cmake && make && make install which comes with gui 
> > discoverability through cmake-gui, embeddability through add_subdirectory 
> > or C++ package managers such as conan, vcpkg, hunter, etc etc. but instead 
> > acting like its own microcosm library where you have to learn yet another 
> > set of commands & invocations if you want to integrate it in your existing 
> > system.
>
> Woah, you're ass is so shinny i can't see the light.

Hi Jean-Michaël,
I would like to apologise about that one, frustration got me in.
That wasn't smart from me, I do respect everyone, even when I disagree
with them.
I didn't mean to insult you, please forgive me, that was a stupid behaviour.

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

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

[Christian Gagneraud]

On Mon, 17 Jun 2019 at 23:06, Jean-Michaël Celerier
 wrote:
>
> > The world is not spinning around Qt, sorry for the bad news.
>
> On that we agree : https://www.jetbrains.com/lp/devecosystem-2019/cpp/
> I mean, I had actual CMake classes with a CMake exam on paper 6 years ago at 
> the university -- you get a few hundreds of new devs on the job market every 
> year out of that one, who *will* know CMake, and won't know qmake / qbs / 
> [...].

Are you insulting this mailing list?
How do you think we made it so far without cmake? Honestly?

The very fact you're discussing qmake and qbs just show that you know
about them, and that you know what they provide cmake cannot provide
(yet).

> > I prefer a transparent self-bootstrapped Qt over an explicit two stages one.
> I (entirely personnally) really do not, - this is anecdotally one of the main 
> objections I've heard about Qt (3k questions just about Qt's configure in SO 
> ! https://stackoverflow.com/search?q=%5Bqt%5D+configure) : not just answering 
> to a standard cmake && make && make install which comes with gui 
> discoverability through cmake-gui, embeddability through add_subdirectory or 
> C++ package managers such as conan, vcpkg, hunter, etc etc. but instead 
> acting like its own microcosm library where you have to learn yet another set 
> of commands & invocations if you want to integrate it in your existing system.

Woah, you're ass is so shinny i can't see the light.

> > Last comment: Please think about [...] Cmake is not yet ready for that.
>
> > embedded Linux
> Oh come on.

Yes, come on, why do i have to define a custom "toolchain file" each
time someone fart?
Can't you just understand the good old gnu configure triplet? Or the
concept of sytem/user wide profile? (qbs profile, qmake specs)
Why does every single project has to provide it's own set of CMake
toolchain files?
Have you ever thought about the problem?

Well, i doubt that. "If it works on my Windows machine, then it works
everywhere", right? (provocative sarcasm really)

> > qnx
> you mean like software companies using Qt do, today ? 
> https://github.com/mapbox/mapbox-gl-native/blob/master/platform/qt/qnx.cmake

I'm gob-smacked!!!
This is awesome.

They can use gcc to build a QNX app... Thanks CMake to allow QNX to
exists... This real-time kernel could never have existed without the
help of CMake.
My first experience with QNX, was.. at least 20 years ago. I'm not
even sure CMake existed back at that time.
But hey, you're revolutionizing the world, i cannot fight obviously...

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

Lol, did you run out of google searches? Honestly i can throw random
links too. Did you click "I'm felling lucky" or what?

> > iOS
>
> ... yes ? https://github.com/sheldonth/ios-cmake

Yeah right, problem solved then! Ship it! Come on, let's do it!

Let's make an announcement:

CMAKE FULLY SUPPORT IOS.

PS: well, not exactly, please carrefully read the small prints.

> Also, just because CMake now has acquired *official* support for iOS does not 
> mean that it hasn't been working for a long time. There were people shipping 
> iOS apps with CMake five years ago - and this is due in part to CMake having 
> a *large* community, unlike qmake / qbs, which means that even if CMake does 
> not directly support $FEATURE, chances are that you can find an 
> aptly-licensed open-source library that you can use to augment your build 
> with and achieve what you want.
> See e.g. all the projects that ship today with 
> https://github.com/leetal/ios-cmake, https://github.com/ruslo/polly, etc etc
> In contrast, how many people are shipping qmake extensions outside of QtCore, 
> as a library for anyone to use ?
>
> > 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
>
> Also, C++Builder was able to ship and advertise CMake support for Android & 
> iOS a year ago so there is no reason Qt cannot do the same : 
> https://community.idera.com/developer-tools/b/blog/posts/new-in-10-2-3-cmake-support-for-ios-and-android
>
> > and whatever next os is coming.
>
> you mean like Fuschia 
> (https://github.com/Kitware/CMake/blob/master/Modules/Platform/Fuchsia.cmake) 
> or maybe actual operating systems built with CMake, such as IncludeOS 
> (https://github.com/includeos/IncludeOS) or ReactOS 
> (https://github.com/reactos/reactos) ? :-)

Man, your google skills outpace me to such an extent that i cannot be
bothered wasted more time...

Chris
___
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

[Development] Qt 5.13.0 RC3 published

[Jani Heikkinen]

Hi!

Qt 5.13.0 RC3 is out. As usual you can get it as an update to existing Qt 
5.13.0 installation. Or you can do clean installation by using Qt online 
installer. 
RC3 is also available as offline installers & source packages which can be 
downloaded from Qt Account or from download.qt.io.

Delta to RC2 as an attachment.

Target is to release these packages as Qt 5.13.0 Final Wed 19th June.

br
Jani Heikkinen
Release Manager
qt5.git
644f8b7006737a89bfa171fcc7df15a312d678d7 Fix openssl 1.1 library configurations
fd1f34192a4b441965abe64c0deb84b831c97a6d Fix qt5.git builds
qt3d:
qtactiveqt:
qtandroidextras:
qtbase:
fc9ae22c88dd085c7c31599037132fc756feeb04 tst_qsslsocket: fix racy test
2c5d21be436ad5f2549cb1a6f40b185e159812a4 H2 auto-test, degrage 
flowControlServerSide
2e7b7e4c90882cef50b293fe8048205a9ca7e5a9 QSslSocket: add and set the 
TLSv1.3-specific PSK callback
90aefe0843a50aede26b8d411f46f3828dae25f1 Add quoting to deal with empty 
${CMAKE_CXX_STANDARD_LIBRARIES}
2ea3e133c369deefeae0605ad2f32aaea52c9e97 Doc: Add Q_OS_WASM documentation
qtcharts:
qtconnectivity:
qtdatavis3d:
qtdeclarative:
qtdoc:
qtgamepad:
qtgraphicaleffects:
qtimageformats:
qtlocation:
qtlottie:
qtmacextras:
qtmultimedia:
qtnetworkauth:
qtpurchasing:
qtquickcontrols:
qtquickcontrols2:
qtremoteobjects:
qtscript:
qtscxml:
qtsensors:
qtserialbus:
qtserialport:
qtspeech:
qtsvg:
qttools:
cc9250477eaa71a3f3ffd050591d4a9d835288ca qdoc: Don't log guessed include paths
c7c3e2f26af0842631c95f054600b6b90ef3675b qdoc: Fix regressions in include path 
handling
qttranslations:
qtvirtualkeyboard:
qtwayland:
qtwebchannel:
qtwebengine:
qtwebengine/src/3rdparty:
qtwebglplugin:
qtwebsockets:
qtwebview:
qtwinextras:
qtx11extras:
qtxmlpatterns:
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

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

[Jean-Michaël Celerier]

> The world is not spinning around Qt, sorry for the bad news.

On that we agree : https://www.jetbrains.com/lp/devecosystem-2019/cpp/
I mean, I had actual CMake classes with a CMake exam on paper 6 years ago
at the university -- you get a few hundreds of new devs on the job market
every year out of that one, who *will* know CMake, and won't know qmake /
qbs / [...].

> I prefer a transparent self-bootstrapped Qt over an explicit two stages
one.

I (entirely personnally) really do not, - this is anecdotally one of the
main objections I've heard about Qt (3k questions just about Qt's configure
in SO ! https://stackoverflow.com/search?q=%5Bqt%5D+configure) : not just
answering to a standard cmake && make && make install which comes with gui
discoverability through cmake-gui, embeddability through add_subdirectory
or C++ package managers such as conan, vcpkg, hunter, etc etc. but instead
acting like its own microcosm library where you have to learn yet another
set of commands & invocations if you want to integrate it in your existing
system.

> Last comment: Please think about [...] Cmake is not yet ready for that.

> embedded Linux
Oh come on.

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

> iOS

... yes ? https://github.com/sheldonth/ios-cmake
Also, just because CMake now has acquired *official* support for iOS does
not mean that it hasn't been working for a long time. There were people
shipping iOS apps with CMake five years ago - and this is due in part to
CMake having a *large* community, unlike qmake / qbs, which means that even
if CMake does not directly support $FEATURE, chances are that you can find
an aptly-licensed open-source library that you can use to augment your
build with and achieve what you want.
See e.g. all the projects that ship today with
https://github.com/leetal/ios-cmake, https://github.com/ruslo/polly, etc
etc
In contrast, how many people are shipping qmake extensions outside of
QtCore, as a library for anyone to use ?

> 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

Also, C++Builder was able to ship and advertise CMake support for Android &
iOS a year ago so there is no reason Qt cannot do the same :
https://community.idera.com/developer-tools/b/blog/posts/new-in-10-2-3-cmake-support-for-ios-and-android

> and whatever next os is coming.

you mean like Fuschia (
https://github.com/Kitware/CMake/blob/master/Modules/Platform/Fuchsia.cmake)
or maybe actual operating systems built with CMake, such as IncludeOS (
https://github.com/includeos/IncludeOS) or ReactOS (
https://github.com/reactos/reactos) ? :-)

Best,
Jean-Michaël

On Mon, Jun 17, 2019 at 11:05 AM Christian Gagneraud 
wrote:

> On Mon, 17 Jun 2019, 20:15 Elvis Stansvik,  wrote:
>
>> Den mån 17 juni 2019 kl 09:12 skrev Christian Gagneraud > >:
>> >
>> > On Mon, 17 Jun 2019, 18:11 Jedrzej Nowacki, 
>> wrote:
>> >>
>> >> On Saturday, June 15, 2019 6:37:24 PM CEST Thiago Macieira wrote:
>> >> > On Saturday, 15 June 2019 02:18:28 PDT Jean-Michaël Celerier wrote:
>> >> > > You can download a CMake static binary (
>> https://cmake.org/download/) that
>> >> >
>> >> > (...)
>> >> >
>> >> > I would prefer that our requirements be present in Linux
>> distributions we
>> >> > declare are supported build environments. If nothing else, our CI
>> will
>> >> > benefit from this.
>> >>
>> >> Let's not pull CI into it. It already
>> >
>> >
>> > Wow! Let's not pull in the system which only goal is to validate the
>> "supported platforms" promise, is it what you mean?
>> > If I need a special cmake to build Qt, then this should be shipped as
>> part of Qt itself, another third-party source tree.
>> > And then it means that I will need to build qt's build system. In other
>> words, I'll have to bootstrap Qt build system.
>> > I thought that it was a big no-no. The main argument to ditch qmake and
>> qbs...
>>
>> Hm, what is the problem with using the official CMake binaries? Isn't
>> that what you'd do on Windows / macOS anyway?
>>
>
> In case you didn't follow the thread, building Qt with cmake requires a
> non-released version of cmake.
>
> The question is:
> By the time qt6 will be out, will the requirement of cmake minimum version
> be met by, say, the latest (two) Ubuntu LTS release? (Or Macos, ...)
>
>
> The answer is that, best case, this is doable if qt6 is not released
> before 2022 or 2024. (Current req. Is unreleased cmake 2.15. assuming the
> minimum req. is not bumped, which is very unlikely given the lack of
> support for Android, iOS, etc...)
>
>
>> If distro X (e.g. *buntu 20.04) happen to ship a sufficient version

[Development] Qt 5.12.4 released

[Jani Heikkinen]

Hi all,

Qt 5.12.4 is released today, see more info from blog post: 
https://blog.qt.io/blog/2019/06/17/qt-5-12-4-released-support-openssl-1-1-1/

Big thanks to everyone involved!

br,
Jani Heikkinen
Release Manager
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

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

[Konstantin Tokarev]

17.06.2019, 12:48, "Mark De Wit" :
>>  -Original Message-
>>  From: Development  On Behalf Of
>>  Konstantin Tokarev
>>  Sent: 06 June 2019 14:30
>>  To: Simon Hausmann ; Bogdan Vatra
>>  ; development@qt-project.org
>>  Subject: Re: [Development] Proposing CMake as build tool for Qt 6
>>
>>  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 alternative is https://github.com/larsch/cmake-precompiled-
>>  header/blob/master/PrecompiledHeader.cmake
>>  which is not so monstrous as cotire
>
> I have used Cotire until recently and would caution against it. The library 
> at its core is a clever idea but its implementation caused a lot of build 
> instability for us. Its current version doesn't work on MSVC with CMake > 
> 3.12, also fails on Mac with AppleClang 8.0 (bad command line parameter). It 
> appears to be unmaintained as my bug reports have gone completely unanswered 
> / not even acknowledged.
>
> In the end I wrote my own pch script that works ok for our scenario. MSVC 
> support is pretty trivial, gcc/clang more awkward because their pch 
> compilation is a separate build step. My script did include some ideas from 
> larsch github repo linked above, but I don't like his approach of injecting 
> build flags into the clang/gcc pch stage (it didn't work for me, I ended up 
> missing critical flags).
>
> I used some ideas from cotire to generate a list of includes to seed each 
> module PCH header file, but maintain updates manually (like MSVC 
> stdafx.h/pch.h approach). I'm sure pch header generation could be automated 
> too...

I think that automatic generation of PCH is a bad idea, leading to wasting 
build time.

-- 
Regards,
Konstantin

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

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

[Mark De Wit]

> -Original Message-
> From: Development  On Behalf Of
> Konstantin Tokarev
> Sent: 06 June 2019 14:30
> To: Simon Hausmann ; Bogdan Vatra
> ; development@qt-project.org
> Subject: Re: [Development] Proposing CMake as build tool for Qt 6
> 
> 
> 
> 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 alternative is https://github.com/larsch/cmake-precompiled-
> header/blob/master/PrecompiledHeader.cmake
> which is not so monstrous as cotire

I have used Cotire until recently and would caution against it.  The library at 
its core is a clever idea but its implementation caused a lot of build 
instability for us.  Its current version doesn't work on MSVC with CMake > 
3.12, also fails on Mac with AppleClang 8.0 (bad command line parameter).  It 
appears to be unmaintained as my bug reports have gone completely unanswered / 
not even acknowledged.

In the end I wrote my own pch script that works ok for our scenario.  MSVC 
support is pretty trivial, gcc/clang more awkward because their pch compilation 
is a separate build step.  My script did include some ideas from larsch github 
repo linked above, but I don't like his approach of injecting build flags into 
the clang/gcc pch stage (it didn't work for me, I ended up missing critical 
flags).

I used some ideas from cotire to generate a list of includes to seed each 
module PCH header file, but maintain updates manually (like MSVC stdafx.h/pch.h 
approach).  I'm sure pch header generation could be automated too...

Mark 

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

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

[Konstantin Tokarev]

17.06.2019, 12:15, "Christian Gagneraud" :
> On Mon, 17 Jun 2019, 21:13 Konstantin Tokarev,  wrote:
>> 17.06.2019, 12:07, "Christian Gagneraud" :
>>> On Mon, 17 Jun 2019, 20:15 Elvis Stansvik,  wrote:
 Den mån 17 juni 2019 kl 09:12 skrev Christian Gagneraud :
>
> On Mon, 17 Jun 2019, 18:11 Jedrzej Nowacki,  wrote:
>>
>> On Saturday, June 15, 2019 6:37:24 PM CEST Thiago Macieira wrote:
>> > On Saturday, 15 June 2019 02:18:28 PDT Jean-Michaël Celerier wrote:
>> > > You can download a CMake static binary (https://cmake.org/download/) 
>> > > that
>> >
>> > (...)
>> >
>> > I would prefer that our requirements be present in Linux distributions 
>> > we
>> > declare are supported build environments. If nothing else, our CI will
>> > benefit from this.
>>
>> Let's not pull CI into it. It already
>
>
> Wow! Let's not pull in the system which only goal is to validate the 
> "supported platforms" promise, is it what you mean?
> If I need a special cmake to build Qt, then this should be shipped as 
> part of Qt itself, another third-party source tree.
> And then it means that I will need to build qt's build system. In other 
> words, I'll have to bootstrap Qt build system.
> I thought that it was a big no-no. The main argument to ditch qmake and 
> qbs...

 Hm, what is the problem with using the official CMake binaries? Isn't
 that what you'd do on Windows / macOS anyway?
>>>
>>> In case you didn't follow the thread, building Qt with cmake requires a 
>>> non-released version of cmake.
>>>
>>> The question is:
>>> By the time qt6 will be out, will the requirement of cmake minimum version 
>>> be met by, say, the latest (two) Ubuntu LTS release? (Or Macos, ...)
>>>
>>> The answer is that, best case, this is doable if qt6 is not released before 
>>> 2022 or 2024. (Current req. Is unreleased cmake 2.15. assuming the minimum 
>>> req. is not bumped, which is very unlikely given the lack of support for 
>>> Android, iOS, etc...)
>>>
 If distro X (e.g. *buntu 20.04) happen to ship a sufficient version
 when it arrives, then great. But having to install the build tool from
 the vendor instead of the distro package manager surely can't be a
 blocker
>>>
>>> Really? Then convince the boot2qt team to force yocto to use the latest 
>>> bleeding edge cmake version for their stable branch...
>>> Good luck with that.
>>>
>>> And then, which is my point, you're asking your customers to build/install 
>>> Qt build system in order to build Qt itself.
>>> That is wrong. The world is not spinning around Qt, sorry for the bad news.
>>> I prefer a transparent self-bootstrapped Qt over an explicit two stages one.
>>>
>>> Right now the cmake build system doesn't respect the initial requirements 
>>> that were used to ditch contenders.
>>>
>>> This is in no way a democratic process.
>>
>> Democracy has no power here.
>>
>> "The Qt Project is a _meritocratic_, consensus-based community interested in 
>> Qt."
>>
>> Decisions are up to tho who does the work.
>
> And those who throw money at it: QtC customers.

Fair point.

>
>>> This is selective hearing, reqs for cmake are artificially lowered while 
>>> reqs for contenders are artificially raised.
>>>
>>> I have no doubt that cmake will be Qt6 build system, this is your choice, 
>>> I'm just asking to stop this simulation, and I'm asking you to take your 
>>> responsibilities, if building Qt6 is not supported on mainstream platforms 
>>> I might consider switching away from Qt.
>>>
>>> Last comment: Please think about embedded Linux, qnx, vxworx, iOS, android 
>>> and whatever next os is coming.
>>> Cmake is not yet ready for that.
>>>
>>> Chris
>>>
 Elvis

>
> Chris
>
>
>> covers installation of the cmake in
>> order to test wip/cmake branch 
>> (https://code.qt.io/cgit/qt/qt5.git/tree/coin/
>> provisioning/common/linux/cmake_linux.sh?h=wip/cmake)
>>
>> Cheers,
>>   Jędrek
>>
>>
>> ___
>> 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
>>
>> --
>> Regards,
>> Konstantin


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

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

[Christian Gagneraud]

On Mon, 17 Jun 2019, 21:13 Konstantin Tokarev,  wrote:

>
>
> 17.06.2019, 12:07, "Christian Gagneraud" :
> > On Mon, 17 Jun 2019, 20:15 Elvis Stansvik,  wrote:
> >> Den mån 17 juni 2019 kl 09:12 skrev Christian Gagneraud <
> chg...@gmail.com>:
> >>>
> >>> On Mon, 17 Jun 2019, 18:11 Jedrzej Nowacki, 
> wrote:
> 
>  On Saturday, June 15, 2019 6:37:24 PM CEST Thiago Macieira wrote:
>  > On Saturday, 15 June 2019 02:18:28 PDT Jean-Michaël Celerier wrote:
>  > > You can download a CMake static binary (
> https://cmake.org/download/) that
>  >
>  > (...)
>  >
>  > I would prefer that our requirements be present in Linux
> distributions we
>  > declare are supported build environments. If nothing else, our CI
> will
>  > benefit from this.
> 
>  Let's not pull CI into it. It already
> >>>
> >>>
> >>> Wow! Let's not pull in the system which only goal is to validate the
> "supported platforms" promise, is it what you mean?
> >>> If I need a special cmake to build Qt, then this should be shipped as
> part of Qt itself, another third-party source tree.
> >>> And then it means that I will need to build qt's build system. In
> other words, I'll have to bootstrap Qt build system.
> >>> I thought that it was a big no-no. The main argument to ditch qmake
> and qbs...
> >>
> >> Hm, what is the problem with using the official CMake binaries? Isn't
> >> that what you'd do on Windows / macOS anyway?
> >
> > In case you didn't follow the thread, building Qt with cmake requires a
> non-released version of cmake.
> >
> > The question is:
> > By the time qt6 will be out, will the requirement of cmake minimum
> version be met by, say, the latest (two) Ubuntu LTS release? (Or Macos, ...)
> >
> > The answer is that, best case, this is doable if qt6 is not released
> before 2022 or 2024. (Current req. Is unreleased cmake 2.15. assuming the
> minimum req. is not bumped, which is very unlikely given the lack of
> support for Android, iOS, etc...)
> >
> >> If distro X (e.g. *buntu 20.04) happen to ship a sufficient version
> >> when it arrives, then great. But having to install the build tool from
> >> the vendor instead of the distro package manager surely can't be a
> >> blocker
> >
> > Really? Then convince the boot2qt team to force yocto to use the latest
> bleeding edge cmake version for their stable branch...
> > Good luck with that.
> >
> > And then, which is my point, you're asking your customers to
> build/install Qt build system in order to build Qt itself.
> > That is wrong. The world is not spinning around Qt, sorry for the bad
> news.
> > I prefer a transparent self-bootstrapped Qt over an explicit two stages
> one.
> >
> > Right now the cmake build system doesn't respect the initial
> requirements that were used to ditch contenders.
> >
> > This is in no way a democratic process.
>
> Democracy has no power here.
>
> "The Qt Project is a _meritocratic_, consensus-based community interested
> in Qt."
>
> Decisions are up to tho who does the work.
>


And those who throw money at it: QtC customers.




> > This is selective hearing, reqs for cmake are artificially lowered while
> reqs for contenders are artificially raised.
> >
> > I have no doubt that cmake will be Qt6 build system, this is your
> choice, I'm just asking to stop this simulation, and I'm asking you to take
> your responsibilities, if building Qt6 is not supported on mainstream
> platforms I might consider switching away from Qt.
> >
> > Last comment: Please think about embedded Linux, qnx, vxworx, iOS,
> android and whatever next os is coming.
> > Cmake is not yet ready for that.
> >
> > Chris
> >
> >> Elvis
> >>
> >>>
> >>> Chris
> >>>
> >>>
>  covers installation of the cmake in
>  order to test wip/cmake branch (
> https://code.qt.io/cgit/qt/qt5.git/tree/coin/
>  provisioning/common/linux/cmake_linux.sh?h=wip/cmake)
> 
>  Cheers,
>    Jędrek
> 
> 
>  ___
>  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
>
>
> --
> Regards,
> Konstantin
>
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

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

[Konstantin Tokarev]

17.06.2019, 12:07, "Christian Gagneraud" :
> On Mon, 17 Jun 2019, 20:15 Elvis Stansvik,  wrote:
>> Den mån 17 juni 2019 kl 09:12 skrev Christian Gagneraud :
>>>
>>> On Mon, 17 Jun 2019, 18:11 Jedrzej Nowacki,  wrote:

 On Saturday, June 15, 2019 6:37:24 PM CEST Thiago Macieira wrote:
 > On Saturday, 15 June 2019 02:18:28 PDT Jean-Michaël Celerier wrote:
 > > You can download a CMake static binary (https://cmake.org/download/) 
 > > that
 >
 > (...)
 >
 > I would prefer that our requirements be present in Linux distributions we
 > declare are supported build environments. If nothing else, our CI will
 > benefit from this.

 Let's not pull CI into it. It already
>>>
>>>
>>> Wow! Let's not pull in the system which only goal is to validate the 
>>> "supported platforms" promise, is it what you mean?
>>> If I need a special cmake to build Qt, then this should be shipped as part 
>>> of Qt itself, another third-party source tree.
>>> And then it means that I will need to build qt's build system. In other 
>>> words, I'll have to bootstrap Qt build system.
>>> I thought that it was a big no-no. The main argument to ditch qmake and 
>>> qbs...
>>
>> Hm, what is the problem with using the official CMake binaries? Isn't
>> that what you'd do on Windows / macOS anyway?
>
> In case you didn't follow the thread, building Qt with cmake requires a 
> non-released version of cmake.
>
> The question is:
> By the time qt6 will be out, will the requirement of cmake minimum version be 
> met by, say, the latest (two) Ubuntu LTS release? (Or Macos, ...)
>
> The answer is that, best case, this is doable if qt6 is not released before 
> 2022 or 2024. (Current req. Is unreleased cmake 2.15. assuming the minimum 
> req. is not bumped, which is very unlikely given the lack of support for 
> Android, iOS, etc...)
>
>> If distro X (e.g. *buntu 20.04) happen to ship a sufficient version
>> when it arrives, then great. But having to install the build tool from
>> the vendor instead of the distro package manager surely can't be a
>> blocker
>
> Really? Then convince the boot2qt team to force yocto to use the latest 
> bleeding edge cmake version for their stable branch...
> Good luck with that.
>
> And then, which is my point, you're asking your customers to build/install Qt 
> build system in order to build Qt itself.
> That is wrong. The world is not spinning around Qt, sorry for the bad news.
> I prefer a transparent self-bootstrapped Qt over an explicit two stages one.
>
> Right now the cmake build system doesn't respect the initial requirements 
> that were used to ditch contenders.
>
> This is in no way a democratic process.

Democracy has no power here.

"The Qt Project is a _meritocratic_, consensus-based community interested in 
Qt."

Decisions are up to tho who does the work.

> This is selective hearing, reqs for cmake are artificially lowered while reqs 
> for contenders are artificially raised.
>
> I have no doubt that cmake will be Qt6 build system, this is your choice, I'm 
> just asking to stop this simulation, and I'm asking you to take your 
> responsibilities, if building Qt6 is not supported on mainstream platforms I 
> might consider switching away from Qt.
>
> Last comment: Please think about embedded Linux, qnx, vxworx, iOS, android 
> and whatever next os is coming.
> Cmake is not yet ready for that.
>
> Chris
>
>> Elvis
>>
>>>
>>> Chris
>>>
>>>
 covers installation of the cmake in
 order to test wip/cmake branch 
 (https://code.qt.io/cgit/qt/qt5.git/tree/coin/
 provisioning/common/linux/cmake_linux.sh?h=wip/cmake)

 Cheers,
   Jędrek


 ___
 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


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

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

[Christian Gagneraud]

On Mon, 17 Jun 2019, 20:15 Elvis Stansvik,  wrote:

> Den mån 17 juni 2019 kl 09:12 skrev Christian Gagneraud  >:
> >
> > On Mon, 17 Jun 2019, 18:11 Jedrzej Nowacki, 
> wrote:
> >>
> >> On Saturday, June 15, 2019 6:37:24 PM CEST Thiago Macieira wrote:
> >> > On Saturday, 15 June 2019 02:18:28 PDT Jean-Michaël Celerier wrote:
> >> > > You can download a CMake static binary (https://cmake.org/download/)
> that
> >> >
> >> > (...)
> >> >
> >> > I would prefer that our requirements be present in Linux
> distributions we
> >> > declare are supported build environments. If nothing else, our CI will
> >> > benefit from this.
> >>
> >> Let's not pull CI into it. It already
> >
> >
> > Wow! Let's not pull in the system which only goal is to validate the
> "supported platforms" promise, is it what you mean?
> > If I need a special cmake to build Qt, then this should be shipped as
> part of Qt itself, another third-party source tree.
> > And then it means that I will need to build qt's build system. In other
> words, I'll have to bootstrap Qt build system.
> > I thought that it was a big no-no. The main argument to ditch qmake and
> qbs...
>
> Hm, what is the problem with using the official CMake binaries? Isn't
> that what you'd do on Windows / macOS anyway?
>

In case you didn't follow the thread, building Qt with cmake requires a
non-released version of cmake.

The question is:
By the time qt6 will be out, will the requirement of cmake minimum version
be met by, say, the latest (two) Ubuntu LTS release? (Or Macos, ...)


The answer is that, best case, this is doable if qt6 is not released before
2022 or 2024. (Current req. Is unreleased cmake 2.15. assuming the minimum
req. is not bumped, which is very unlikely given the lack of support for
Android, iOS, etc...)


> If distro X (e.g. *buntu 20.04) happen to ship a sufficient version
> when it arrives, then great. But having to install the build tool from
> the vendor instead of the distro package manager surely can't be a
> blocker
>

Really? Then convince the boot2qt team to force yocto to use the latest
bleeding edge cmake version for their stable branch...
Good luck with that.

And then, which is my point, you're asking your customers to build/install
Qt build system in order to build Qt itself.
That is wrong. The world is not spinning around Qt, sorry for the bad news.
I prefer a transparent self-bootstrapped Qt over an explicit two stages one.

Right now the cmake build system doesn't respect the initial requirements
that were used to ditch contenders.

This is in no way a democratic process.
This is selective hearing, reqs for cmake are artificially lowered while
reqs for contenders are artificially raised.

I have no doubt that cmake will be Qt6 build system, this is your choice,
I'm just asking to stop this simulation, and I'm asking you to take your
responsibilities, if building Qt6 is not supported on mainstream platforms
I might consider switching away from Qt.

Last comment: Please think about embedded Linux, qnx, vxworx, iOS, android
and whatever next os is coming.
Cmake is not yet ready for that.

Chris




> Elvis
>
> >
> > Chris
> >
> >
> >> covers installation of the cmake in
> >> order to test wip/cmake branch (
> https://code.qt.io/cgit/qt/qt5.git/tree/coin/
> >> provisioning/common/linux/cmake_linux.sh?h=wip/cmake)
> >>
> >> Cheers,
> >>   Jędrek
> >>
> >>
> >> ___
> >> 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

[Konstantin Tokarev]

15.06.2019, 05:29, "Thiago Macieira" :
> I wonder if Assistant as a standalone application still makes sense.

Do we have another standalone qch viewer application?

-- 
Regards,
Konstantin

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

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

[Miguel Costa]

From: Development  On Behalf Of Thiago 
Macieira
Sent: Samstag, 15. Juni 2019 04:27
>
> I wonder if Assistant as a standalone application still makes sense. Is it 
> used by the VS Add-in?

No, it's not used by the VS add-in (help for Qt classes is opened in default 
browser).

BR,
--Miguel

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

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

[Elvis Stansvik]

Den mån 17 juni 2019 kl 09:12 skrev Christian Gagneraud :
>
> On Mon, 17 Jun 2019, 18:11 Jedrzej Nowacki,  wrote:
>>
>> On Saturday, June 15, 2019 6:37:24 PM CEST Thiago Macieira wrote:
>> > On Saturday, 15 June 2019 02:18:28 PDT Jean-Michaël Celerier wrote:
>> > > You can download a CMake static binary (https://cmake.org/download/) that
>> >
>> > (...)
>> >
>> > I would prefer that our requirements be present in Linux distributions we
>> > declare are supported build environments. If nothing else, our CI will
>> > benefit from this.
>>
>> Let's not pull CI into it. It already
>
>
> Wow! Let's not pull in the system which only goal is to validate the 
> "supported platforms" promise, is it what you mean?
> If I need a special cmake to build Qt, then this should be shipped as part of 
> Qt itself, another third-party source tree.
> And then it means that I will need to build qt's build system. In other 
> words, I'll have to bootstrap Qt build system.
> I thought that it was a big no-no. The main argument to ditch qmake and qbs...

Hm, what is the problem with using the official CMake binaries? Isn't
that what you'd do on Windows / macOS anyway?

If distro X (e.g. *buntu 20.04) happen to ship a sufficient version
when it arrives, then great. But having to install the build tool from
the vendor instead of the distro package manager surely can't be a
blocker?

Elvis

>
> Chris
>
>
>> covers installation of the cmake in
>> order to test wip/cmake branch (https://code.qt.io/cgit/qt/qt5.git/tree/coin/
>> provisioning/common/linux/cmake_linux.sh?h=wip/cmake)
>>
>> Cheers,
>>   Jędrek
>>
>>
>> ___
>> 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] CI is back online

[Heikki Halmet]

Hi,

We had some issues in Gerrit during this weekend. Gerrit started to sent extra 
emails on merge builds during Friday evening. That's why CI was shut down on 
Friday evening.

Now issues are fixed and CI is back online.




Ystävällisin terveisin / Kind regards,

Heikki Halmet
Software Engineer | CI Lead
Release and Test Automation | CI Team
The Qt Company | Finland | Oulu


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

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

[Christian Gagneraud]

On Mon, 17 Jun 2019, 18:11 Jedrzej Nowacki,  wrote:

> On Saturday, June 15, 2019 6:37:24 PM CEST Thiago Macieira wrote:
> > On Saturday, 15 June 2019 02:18:28 PDT Jean-Michaël Celerier wrote:
> > > You can download a CMake static binary (https://cmake.org/download/)
> that
> >
> > (...)
> >
> > I would prefer that our requirements be present in Linux distributions we
> > declare are supported build environments. If nothing else, our CI will
> > benefit from this.
>
> Let's not pull CI into it. It already


Wow! Let's not pull in the system which only goal is to validate the
"supported platforms" promise, is it what you mean?
If I need a special cmake to build Qt, then this should be shipped as part
of Qt itself, another third-party source tree.
And then it means that I will need to build qt's build system. In other
words, I'll have to bootstrap Qt build system.
I thought that it was a big no-no. The main argument to ditch qmake and
qbs...

Chris


covers installation of the cmake in
> order to test wip/cmake branch (
> https://code.qt.io/cgit/qt/qt5.git/tree/coin/
> provisioning/common/linux/cmake_linux.sh?h=wip/cmake
> 
> )
>
> Cheers,
>   Jędrek
>
>
> ___
> 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

[Joerg Bornemann]

On 6/15/19 12:06 PM, Sérgio Martins via Development wrote:

> The current definition of "debug" for MSVC Qt is:
> 1) Unoptimized  (via /O flags)
> 2) Has debug symbols
> 3) Links to another c++ runtime library, which lets you debug into 
> (/MDd). (And this is what prevents you from mixing release Qt with debug 
> app)
> 
> 
> The idea above would be to drop 3). On linux you don't link to a debug 
> libstdc++ either and you don't complain :)
> 
> 
> But there might be problems:
> 
> - cmake -DCMAKE_BUILD_TYPE=Debug means /MDd ?
> - The _DEBUG macro currently comes from /MDd, some users might be using 
> it to detect debug builds.
> - MDd is useful to enable asserts in the C++ library. This argument is 
> strong on Windows, as you don't have valgrind there (or at least an 
> equivalent that doesn't suck too much).

This will break every user project that's build in debug mode with 
Visual Studio's toolchain (whichever currently available build tool you 
use), because it builds by default with /MDd and will be incompatible 
with Qt. I fear we have to accept what this environment forces upon us.


Cheers,

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

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

[Jedrzej Nowacki]

On Saturday, June 15, 2019 6:37:24 PM CEST Thiago Macieira wrote:
> On Saturday, 15 June 2019 02:18:28 PDT Jean-Michaël Celerier wrote:
> > You can download a CMake static binary (https://cmake.org/download/) that
> 
> (...)
> 
> I would prefer that our requirements be present in Linux distributions we
> declare are supported build environments. If nothing else, our CI will
> benefit from this.

Let's not pull CI into it. It already covers installation of the cmake in 
order to test wip/cmake branch (https://code.qt.io/cgit/qt/qt5.git/tree/coin/
provisioning/common/linux/cmake_linux.sh?h=wip/cmake)

Cheers,
  Jędrek


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