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

[Simon Hausmann]

Am 13.06.19 um 09:42 schrieb Lars Knoll:
> Hi all,
>
> After all the discussion, lets go back to the original proposal. We can see 
> from the discussions that there is still work to be done, but I can’t find 
> anything that sounds like a real showstopper.
>
> The two missing features that were voiced as a concern (if I didn’t miss 
> anything in the thread) where multi arch/fat binary support for iOS and PCH 
> support. I also heard that the people working on it are confident they can 
> get this fixed in time for Qt 6, something I’m happy with for now. 
> Nevertheless, I think it would be good if the team working on the cmake port 
> could summarise how/when they are planning to fix this.

So the status regarding those two items is good:


     1) Cristian implemented PCH support in CMake itself and it's part 
of the 3.16 release (thank you Cristian!).

     2) We've had good discussions with CMake folks regarding fat binary 
support for iOS. The basics of the iOS support have been merged into 
qtbase's wip/cmake branch and Cristian picked up Tor Arne's patch for 
cmake and continued working on it (supporting ninja, using new 
architecture selection variable, and whatever else feedback comes).


> One additional concern was multi arch builds for Android, but I don’t think 
> that counts as a concern as qmake does not support this neither (so it would 
> be a new feature).

In the meantime this has landed as a new feature on the qmake side and 
Leander, Liang, Alexandru and Cristian have looked at the cmake side of 
it. Using a self-referencing external project trick, Cristian found a 
way to make this work for application builds (which is cool!).


> Finally, there was a concern around qmake support for users of Qt. This is 
> something I have discussed with the team in the past, and it is a strong 
> requirement that qmake will continue working as a build system for our users 
> at least for the foreseeable future. This can and will be solved by cmake 
> creating the required files to support qmake. Btw, this is also a hard 
> requirement to be able to change build system repository by repository, so 
> that we don’t have to do a all or nothing switch of all our repos.


The CI system has support for building with cmake or qmake on a 
per-configuration basis and Alexandru has continued work on the qmake 
support against cmake built modules. The work isn't complete yet, but 
IMO this should not prevent us from going forward.


> In summary, I do agree with and support the initial proposal by Simon to 
> merge wip/cmake into wip/qt6.


Meanwhile, the target has changed from wip/qt6 to dev, but otherwise 
we're looking at preparing a merge soon for wider review.


Simon


>> On 6 Jun 2019, at 14:43, Sérgio Martins  wrote:
>>
>> On Thu, Jun 6, 2019 at 12:45 PM Simon Hausmann  wrote:
>>> Hi,
>>>
>>> In the past months we, some developers from the Qt Company and KDAB,
>>> have made good progress on the port of Qt to use CMake as build tool.
>> +1, simply because we only have 1 contender so far.
>>
>> Thanks for stepping up and doing the work.
>>
>> Regards,
>> Sérgio Martins
>> ___
>> Development mailing list
>> Development@qt-project.org
>> https://lists.qt-project.org/listinfo/development
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

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

[Denis Shienkov]

Jean-Michaël Celerier,

WOW, many thanks.. :)

But, as I can see, with CMake it is very over-complicated (as for me as a
noob). For this I need to
waste a lot of time to search in google, on stackoverflow and etc. I think,
that even a week is not
enough for this (to know for all CMake keywords and features which are
required to make a custom
cross-toolchain).  Unlike to QBS, where I spent a hour to *create* and
*debug* of a custom toolchain
(basically to study of a compiler datasheet with it commands).

But, OK, many thanks for the example, anyway. :)

BR,
Denis

ср, 19 июн. 2019 г. в 10:44, Jean-Michaël Celerier <
jeanmichael.celer...@gmail.com>:

> Here's a basic one, with which I managed to compile & link simple stuff -
> disclaimer : based on the ideas found in a google search for "keil"
> "cmake".
> I only tested on linux with wine. God is that compiler invocation ugly :)
>
> Example project I used (with dummy foo.c/bar.c/"space out" subfolder not
> attached) :
>
> cmake_minimum_required(VERSION 3.14)
> project(foo C)
>
> add_executable(foo
> foo.c
> "space out/bar.c"
> )
>
> target_include_directories(foo
> PRIVATE
>   "${CMAKE_CURRENT_SOURCE_DIR}"
>   "${CMAKE_CURRENT_BINARY_DIR}"
>   "space out"
> )
> target_compile_options(foo
> PRIVATE
>   COMPACT
> )
> target_compile_definitions(foo
> PRIVATE
>   hello
>   toto="1"
> )
>
> Best,
> Jean-Michaël
>
> On Tue, Jun 18, 2019 at 1:44 PM Denis Shienkov 
> wrote:
>
>> > Matthew Woehlke
>>
>> > The difference between QBS and CMake is like the difference between a
>> > bright-eyed recruit just out of school and a grizzled veteran.
>>
>> Ok, then, please, provide a simple toolchain file to use e.g. a bare-metal 
>> KEIL C51 [1] compiler. And then, we will to see, how it does in QBS and in 
>> CMake. Who will win then?
>>
>> PS: Of course, my question does not related to Qt build tool, it is a common 
>> question. :)
>>
>> [1] http://www.keil.com/support/man/docs/c51/c51_cm_cmdprompt.htm
>>
>> BR,
>>
>> Denis
>>
>> ___
>> 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

[Jean-Michaël Celerier]

Here's a basic one, with which I managed to compile & link simple stuff -
disclaimer : based on the ideas found in a google search for "keil"
"cmake".
I only tested on linux with wine. God is that compiler invocation ugly :)

Example project I used (with dummy foo.c/bar.c/"space out" subfolder not
attached) :

cmake_minimum_required(VERSION 3.14)
project(foo C)

add_executable(foo
foo.c
"space out/bar.c"
)

target_include_directories(foo
PRIVATE
  "${CMAKE_CURRENT_SOURCE_DIR}"
  "${CMAKE_CURRENT_BINARY_DIR}"
  "space out"
)
target_compile_options(foo
PRIVATE
  COMPACT
)
target_compile_definitions(foo
PRIVATE
  hello
  toto="1"
)

Best,
Jean-Michaël

On Tue, Jun 18, 2019 at 1:44 PM Denis Shienkov 
wrote:

> > Matthew Woehlke
>
> > The difference between QBS and CMake is like the difference between a
> > bright-eyed recruit just out of school and a grizzled veteran.
>
> Ok, then, please, provide a simple toolchain file to use e.g. a bare-metal 
> KEIL C51 [1] compiler. And then, we will to see, how it does in QBS and in 
> CMake. Who will win then?
>
> PS: Of course, my question does not related to Qt build tool, it is a common 
> question. :)
>
> [1] http://www.keil.com/support/man/docs/c51/c51_cm_cmdprompt.htm
>
> BR,
>
> Denis
>
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
>


Keil.cmake
Description: Binary data


KeilLink.cmake
Description: Binary data


KeilCompile.cmake
Description: Binary data
___
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 23:55:44 PDT Joerg Bornemann wrote:
> Sure, I guess even for Qt 5 a configure option -no-debug-runtime or such
> would make sense.

We've lived with this for 20 years, we can wait a few more.

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

[Denis Shienkov]

> Matthew Woehlke

> The difference between QBS and CMake is like the difference between a
> bright-eyed recruit just out of school and a grizzled veteran.

Ok, then, please, provide a simple toolchain file to use e.g. a
bare-metal KEIL C51 [1] compiler. And then, we will to see, how it
does in QBS and in CMake. Who will win then?

PS: Of course, my question does not related to Qt build tool, it is a
common question. :)

[1] http://www.keil.com/support/man/docs/c51/c51_cm_cmdprompt.htm

BR,

Denis
___
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:
> Basically your argumentation is: I'm right, they are all wrong. Only
> CMake can save us all.

No, that is not my argumentation at all. Congratulations, you managed to 
come up with an ad-hominem strawman!

My actual argumentation is based on logic and consistency.

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

[Konrad Rosenbaum]

On 6/17/19 5:09 PM, Thiago Macieira wrote:

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


Yes please. There is at least one user who loves Qt and dislikes 
QtCreator. While it is possible to view Qt Help in a browser, it is more 
comfortable to use Assistant with its specialized search.



    Konrad

___
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 20:24, Kevin Kofler  wrote:
>
> 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.
>
> Of course there are examples where it is clear cut (but as Thiago pointed
> out, many projects get it wrong even in such cases). But see your earlier
> --with-pcre example: typically, building with PCRE support also enables some
> feature that depends on it. This is the case for many such switches in
> practice.
>
> And your --with-pkgversion and --with-bugurl cases show another use of
> --with that is completely unrelated to the external dependencies: passing
> some non-boolean value to the configure script. In CMake, those would just
> be, e.g.: -DBUG_URL:STRING=…

Basically your argumentation is: I'm right, they are all wrong. Only
CMake can save us all.

No very convincing.

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]

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.

Of course there are examples where it is clear cut (but as Thiago pointed 
out, many projects get it wrong even in such cases). But see your earlier
--with-pcre example: typically, building with PCRE support also enables some 
feature that depends on it. This is the case for many such switches in 
practice.

And your --with-pkgversion and --with-bugurl cases show another use of
--with that is completely unrelated to the external dependencies: passing 
some non-boolean value to the configure script. In CMake, those would just 
be, e.g.: -DBUG_URL:STRING=…

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

[Joerg Bornemann]

On 6/17/19 5:26 PM, Thiago Macieira wrote:
> 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.

Sure, I guess even for Qt 5 a configure option -no-debug-runtime or such 
would make sense.


BR,

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

[Joerg Bornemann]

On 6/17/19 6:46 PM, Matthew Woehlke wrote:
> 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.

This is very true. The problem build tools are solving is complex.
When designing a build tool you can choose between simple and powerful.
Qbs chose the latter.

However, one can design a powerful build tool with a front-end language 
that doesn't make you want to scratch your eyes out.

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

I wouldn't know where qbs gets "confused".
Don't spread false information and let it die in peace, thanks.

On the topic of why build tools ignite such hot discussions I have my 
own theory: Experience shows that Jane Developer sees the build tool as 
necessary evil. She doesn't give a damn about details and grudgingly 
invests time in learning as much as is needed for the task at hand. Over 
time she gets a specialist - unwillingly - and defends this investment 
made with teeth and claws.


BR,

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

[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] 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

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

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

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

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

[Scott Bloom]

On Saturday, 15 June 2019 12:22:34 PDT Bogdan Vatra via Development wrote:
> > Why must they be built in one go? Why can't they be separate builds 
> > stitched together? Or even completely separate builds as on Linux 
> > and all the other Unix?
> 
>   Because qmake can build them in one go and last but not least is 
> very convenient. Because a "new" buildsystem should do more than the 
> existing one, not less :).

That only means a "nice to have", not "must have", feature. Sure it's 
convenient, but how often do you really need both and can't simply build twice? 
My Windows build is slow enough as is[*], I'd probably welcome the separation.

Note: with qmake's NMake generator, you *can* type "make debug" and it'll only 
compile the debug sub-targets. That doesn't work with the Unix Makefile one, so 
it won't work for macOS.

[* because I build on my IT-provided dual-core laptop, which comes loaded with 
IT-provided virus scanners, data-loss prevention tools, etc.]


As a big CMake fan, I would love to see the whole QMake -> CMake conversion go 
forward.

To this point, and this point only, the following is what my company uses to 
build debug and release on windows

cmake --build . --config Debug --config RelWithDebInfo  --target ALL_BUILD

For linux, we don’t have a method...

Scott


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

16.06.2019, 00:22, "Thiago Macieira" :
> On Saturday, 15 June 2019 12:22:34 PDT Bogdan Vatra via Development wrote:
>>  > Why must they be built in one go? Why can't they be separate builds
>>  > stitched together? Or even completely separate builds as on Linux and all
>>  > the other Unix?
>>
>>    Because qmake can build them in one go and last but not least is very
>>  convenient. Because a "new" buildsystem should do more than the existing
>>  one, not less :).
>
> That only means a "nice to have", not "must have", feature. Sure it's
> convenient, but how often do you really need both and can't simply build
> twice? My Windows build is slow enough as is[*], I'd probably welcome the
> separation.
>
> Note: with qmake's NMake generator, you *can* type "make debug" and it'll only
> compile the debug sub-targets. That doesn't work with the Unix Makefile one,
> so it won't work for macOS.
>
> [* because I build on my IT-provided dual-core laptop, which comes loaded with
> IT-provided virus scanners, data-loss prevention tools, etc.]
>
>>  > But it has the most support base and the most experience out there, which
>>  > was ostensibly the reason I posted. If users and packagers have problems,
>>  > the pool of people who can help is much bigger.
>>
>>    IMHO "the most support base and the most experience out there" it's just
>>  an appearance, or at least all these "support" and "experience" doesn't
>>  apply to Qt,
>
> Sorry, I disagree. There being more users, more posts on StackOverflow, more.
> I projects using it is not an appearance. It's a fact. Usually, that has a
> strong correlation with quality and the ability to obtain help.

CMake is well-known for its ability to create artifical difficulties, so there 
is no wonder
that there are more posts on StackOverflow :)

>
>>  I'll reiterate a few examples :
>>   - no PCH (in decades)
>>   - no iOS (it seems we need to wait for 3.15 to have *some* support, let's
>>  not forget that iOS it's over a decade old)
>>   - no multi ABIs builds in one go (needed for msvc and useful also for
>>  Android).
>
> I'm not claiming those existed or discounting the value of having those. And
> in the case of iOS builds, the absolute necessity thereof, before 6.0 is out.
>
> What I'm saying is that once we've got all the necessary pieces and we're
> trying to build it, we will still have problems and my post was about ensuring
> we had a robust enough tool and community to help us out. We will have
> problems, whichever tool it is. My objective was to figure out how to solve
> them afterwards.
>
> Granted, the iOS support being so new to the tool does not inspire
> confidence...
>
>>    My *hunch* is that 3.15 won't be enough to build all Qt platforms and
>>  we'll probably needs to wait a little bit more. IMHO cmake superiority it's
>>  just a myth, because, obviously, in *this moment* qmake is a superior
>>  buildsystem *for Qt*.
>
> Again, my post was not about technical superiority. It was about community and
> robustness.
>
>>    Again, I want to highlight the fact that I don't want to change TQC
>>  decision regarding Qt6 and CMake, my comments are only for the sake of the
>>  truth.
>
> And I will point out that this is not a TQtC decision, but a Qt Project
> decision, although heavily influenced by the TQtC developers supporting the
> company's position and that company's decision to cut development of the other
> contender solution.
>
> BTW, the Meson developers contacted me after I posted my email last time and
> asked if we were willing to investigate changing to it. But they didn't offer
> and I didn't see anyone else stepping up to help us in the actual migration.
> --
> 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

-- 
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 Saturday, 15 June 2019 12:22:34 PDT Bogdan Vatra via Development wrote:
> > Why must they be built in one go? Why can't they be separate builds
> > stitched together? Or even completely separate builds as on Linux and all
> > the other Unix?
> 
>   Because qmake can build them in one go and last but not least is very
> convenient. Because a "new" buildsystem should do more than the existing
> one, not less :).

That only means a "nice to have", not "must have", feature. Sure it's 
convenient, but how often do you really need both and can't simply build 
twice? My Windows build is slow enough as is[*], I'd probably welcome the 
separation.

Note: with qmake's NMake generator, you *can* type "make debug" and it'll only 
compile the debug sub-targets. That doesn't work with the Unix Makefile one, 
so it won't work for macOS.

[* because I build on my IT-provided dual-core laptop, which comes loaded with 
IT-provided virus scanners, data-loss prevention tools, etc.]

> > But it has the most support base and the most experience out there, which
> > was ostensibly the reason I posted. If users and packagers have problems,
> > the pool of people who can help is much bigger.
> 
>   IMHO "the most support base and the most experience out there" it's just
> an appearance, or at least all these "support" and "experience" doesn't
> apply to Qt,

Sorry, I disagree. There being more users, more posts on StackOverflow, more. 
I projects using it is not an appearance. It's a fact. Usually, that has a 
strong correlation with quality and the ability to obtain help.

> I'll reiterate a few examples :
>  - no PCH (in decades)
>  - no iOS (it seems we need to wait for 3.15 to have *some* support, let's
> not forget that iOS it's over a decade old)
>  - no multi ABIs builds in one go (needed for msvc and useful also for
> Android).

I'm not claiming those existed or discounting the value of having those. And 
in the case of iOS builds, the absolute necessity thereof, before 6.0 is out.

What I'm saying is that once we've got all the necessary pieces and we're 
trying to build it, we will still have problems and my post was about ensuring 
we had a robust enough tool and community to help us out. We will have 
problems, whichever tool it is. My objective was to figure out how to solve 
them afterwards.

Granted, the iOS support being so new to the tool does not inspire 
confidence...

>   My *hunch* is that 3.15 won't be enough to build all Qt platforms and
> we'll probably needs to wait a little bit more. IMHO cmake superiority it's
> just a myth, because, obviously, in *this moment* qmake is a superior
> buildsystem *for Qt*.

Again, my post was not about technical superiority. It was about community and 
robustness.

>   Again, I want to highlight the fact that I don't want to change TQC
> decision regarding Qt6 and CMake, my comments are only for the sake of the
> truth.

And I will point out that this is not a TQtC decision, but a Qt Project 
decision, although heavily influenced by the TQtC developers supporting the 
company's position and that company's decision to cut development of the other 
contender solution.

BTW, the Meson developers contacted me after I posted my email last time and 
asked if we were willing to investigate changing to it. But they didn't offer 
and I didn't see anyone else stepping up to help us in the actual migration.
-- 
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

[Bogdan Vatra via Development]

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

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

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

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

BogDan.


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

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

[Thiago Macieira]

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

> > The only difficult part I see is enforcing the suffix. On Mac we've had
> > problems with this, since a debug-only build is un-suffixed. Maybe it's
> > time to rethink the strategy and make the suffix optional altogether
> > (using the lib infix feature). On Windows, we should stop enforcing that
> > unoptimised builds be -MDd and make it easy for people to debug into -MD
> > libraries. Hardly anyone ever debugs into Microsoft's libraries...
> 
> I think libs built with -MDd are a must to enable debug builds for your
> application. AFAIK (if I'm wrong I apologize) you can't mix debug apps with
> release libs.

You can't mix -MD with -MDd libs, that's true. But the thing is: that's not 
the switch that controls whether you can debug or not. The true control is the 
optimisation level (-O0) and presence of debug symbols (-Z7). So, is there any 
reason we can't have -MD -O0 -Z7?

And especially for MinGW, since there is no -MD or -MDd switch, the control is 
really artificial.

> So, as long as we need to provide libs, (qml) plugins  for debug & release I
> think building them in one go is a must have feature.

Why must they be built in one go? Why can't they be separate builds stitched 
together? Or even completely separate builds as on Linux and all the other 
Unix?

> > 2 years in the wild was not for all features, it was for the buildsystem
> > itself and the major features. But we need to build with the version that
> > comes with the host systems that we are targetting (if they ship tools
> > like this in the first place; Windows doesn't).
> > 
> > That means that the iOS support only needs to be present in whatever
> > version of CMake that Homebrew installs. Since Homebrew always has the
> > latest, this is not an impediment.
> > 
> > But if we want to build on Ubuntu 16.04, then that three year old
> > version's
> > CMake needs to be sufficient for a native build of Qt and whatever cross-
> > builds get targeted from Linux (Android and QNX, I'd guess). For Qt 6, I'd
> > just recommend raising the minimum to 18.04...
> 
>   What makes you think that you can build Qt for any platform with cmake
> found in Ubuntu 16.04 (or any later version) ?

Nothing. I just chose a version number of Ubuntu out of the blue as an 
example.

>   According to https://code.qt.io/cgit/qt/qtbase.git/tree/CMakeLists.txt?
> h=wip/cmake#n1 Qt needs CMake *3.15.0* which is not even released. This
> means you'll need *NEXT* Ubuntu LTS (20.04?) to build Qt, this means we
> should put Qt6 on pause until 2022 :).

That's concerning.

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

But it has the most support base and the most experience out there, which was 
ostensibly the reason I posted. If users and packagers have problems, the pool 
of people who can help is much bigger.

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

Whether we need to require such a thing is a point of discussion for the Qt 
6.0 release. That's the same as requirements on libraries: if we require a 
PCRE2 or Wayland library that is so new that none but the rolling-release 
distributions have at the time of launch, we'll see a slower adoption of Qt 6.

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.

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

[Sérgio Martins via Development]

On 2019-06-15 07:45, Bogdan Vatra via Development wrote:

Hi,

În ziua de joi, 13 iunie 2019, la 18:22:14 EEST, Thiago Macieira a 
scris:
On Thursday, 13 June 2019 01:06:06 PDT Bogdan Vatra via Development 
wrote:

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

I wouldn't call that a hard requirement. Separate builds for debug and 
for
release are acceptable, the same way that we've ostensibly had support 
for
shared-and-release builds but in practice they're always built 
separately.


The only difficult part I see is enforcing the suffix. On Mac we've 
had
problems with this, since a debug-only build is un-suffixed. Maybe 
it's time
to rethink the strategy and make the suffix optional altogether (using 
the
lib infix feature). On Windows, we should stop enforcing that 
unoptimised
builds be -MDd and make it easy for people to debug into -MD 
libraries.

Hardly anyone ever debugs into Microsoft's libraries...



I think libs built with -MDd are a must to enable debug builds for your
application. AFAIK (if I'm wrong I apologize) you can't mix debug apps 
with

release libs.
So, as long as we need to provide libs, (qml) plugins  for debug & 
release I

think building them in one go is a must have feature.



Depends what you mean by "debug build".

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





Regards,
--
Sérgio Martins | sergio.mart...@kdab.com | Senior Software Engineer
Klarälvdalens Datakonsult AB, a KDAB Group company
Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322)
KDAB - The Qt, C++ and OpenGL Experts
___
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]

Hello :)

> What makes you think that you can build Qt for any platform with cmake
found
in Ubuntu 16.04 (or any later version) ?

You can download a CMake static binary (https://cmake.org/download/) that
runs fine on Ubuntu 16.04 (or 12.04 or CentOS 6 for that matters) - and it
wouldn't be hard to have a bootstrap script that builds or fetches a
recenter CMake if the local version is not up-to-date - after all, you're
talking about building Qt 6 on a system that already ships with Qt 5.5 so
you're not that concerned with using your distro's packages. That's what
tools like vcpkg do for instance (and that's what Qt itself currently does
- if the status quo was kept, building Qt 6 would start by building Qt 6's
qmake anyways).

> It has the least features and it has the ugliest syntax than the
alternatives qmake and QBS.

It has enough features to be able to implement
https://bugreports.qt.io/browse/QTBUG-73925 and I think that we are all
pretty confident that https://bugreports.qt.io/browse/QTBUG-74612 will work
out. If there are other features request / missing features for the CMake
build system they should be added - so far, I think that the CMake people
have been responsive regarding patches that were needed to achieve the Qt
build system. If there's no one doing the same work for QBS, how can you
expect Qt to migrate to it ?

Also, it is much more maintained and active (
https://github.com/qbs/qbs/graphs/contributors?from=2018-06-15=2019-06-15=c
vs
https://github.com/Kitware/CMake/graphs/contributors?from=2018-06-15=2019-06-15=c)
which should be a prime concern for any software project leveraging another
software project - that is, will it be dead in 5 years. The odds for CMake
are I think much smaller than the odds for qbs.

Finally, CMake's main maintainer has historically be open to alternative
front-end languages for CMake if someone actually puts the work in :
https://cmake.org/pipermail/cmake-developers/2016-January/027379.html ;
what would the state of C++ build systems be if the work and energy that
was put towards QBS was instead put in contributing a similar declarative
frontend to CMake is left as a thought exercice to the reader :)

Best,
Jean-Michaël


On Sat, Jun 15, 2019 at 8:46 AM Bogdan Vatra via Development <
development@qt-project.org> wrote:

> Hi,
>
> În ziua de joi, 13 iunie 2019, la 18:22:14 EEST, Thiago Macieira a scris:
> > On Thursday, 13 June 2019 01:06:06 PDT Bogdan Vatra via Development
> wrote:
> > > Hi,
> > >
> > >   There is one more missing feature to add to your list: build & debug
> > >
> > > builds for msvc in one go (same as qmake does now, a single "make"
> command
> > > will build both targets).
> >
> > I wouldn't call that a hard requirement. Separate builds for debug and
> for
> > release are acceptable, the same way that we've ostensibly had support
> for
> > shared-and-release builds but in practice they're always built
> separately.
> >
> > The only difficult part I see is enforcing the suffix. On Mac we've had
> > problems with this, since a debug-only build is un-suffixed. Maybe it's
> time
> > to rethink the strategy and make the suffix optional altogether (using
> the
> > lib infix feature). On Windows, we should stop enforcing that unoptimised
> > builds be -MDd and make it easy for people to debug into -MD libraries.
> > Hardly anyone ever debugs into Microsoft's libraries...
> >
>
> I think libs built with -MDd are a must to enable debug builds for your
> application. AFAIK (if I'm wrong I apologize) you can't mix debug apps
> with
> release libs.
> So, as long as we need to provide libs, (qml) plugins  for debug & release
> I
> think building them in one go is a must have feature.
>
> > >   Also I wonder when do you plan to release Qt6? Because according to
> > >
> > > Thiago's "what a buildsystem must to have list" he mentioned that the
> > > buildsystem should be at least 2 years in the wild. If the needed cmake
> > > support is not implemented yet, are you going to delay Qt 6 release (I
> > > won't mid to use C++20 in Qt 6 :) ) just to give time to cmake to
> mature?
> > > Or that (part of the) list was just an excuse for TQC to ditch QBS ;-).
> >
> > 2 years in the wild was not for all features, it was for the buildsystem
> > itself and the major features. But we need to build with the version that
> > comes with the host systems that we are targetting (if they ship tools
> like
> > this in the first place; Windows doesn't).
> >
> > That means that the iOS support only needs to be present in whatever
> version
> > of CMake that Homebrew installs. Since Homebrew always has the latest,
> this
> > is not an impediment.
> >
> > But if we want to build on Ubuntu 16.04, then that three year old
> version's
> > CMake needs to be sufficient for a native build of Qt and whatever cross-
> > builds get targeted from Linux (Android and QNX, I'd guess). For Qt 6,
> I'd
> > just recommend raising the minimum to 18.04...
>
>   What makes you think that you can 

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

[Kevin Kofler]

Bogdan Vatra via Development wrote:
>   According to https://code.qt.io/cgit/qt/qtbase.git/tree/CMakeLists.txt?
> h=wip/cmake#n1 Qt needs CMake *3.15.0* which is not even released. This
> means you'll need *NEXT* Ubuntu LTS (20.04?) to build Qt, this means we
> should put Qt6 on pause until 2022 :).

At least that would give us 2 more years (than currently planned, i.e., 3 
more years from now) until the API and ABI break that breaks all our code 
yet again, so that wouldn't be a bad thing IMHO. :-)

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

[Bogdan Vatra via Development]

Hi,

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

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

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

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

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

Cheers,
BogDan.


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

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

[Thiago Macieira]

On Friday, 14 June 2019 15:11:42 PDT Lisandro Damián Nicanor Pérez Meyer 
wrote:
> That really sounds like a nice solution. I don't know if it uses
> private headers or not. If it does it might need to be updated in case
> a future revision breaks it, otherwise it should be quite
> straightforward. And make Qt a little bit slimmer too.

It does, but that should be duplicated inside the tool. It uses the QDBusUtil 
namespace for checking the validity of certain strings and for the printing of 
D-Bus messages that QVariant does not know how to convert. The latter should 
become API and therefore hardcoded in the tool.

-- 
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 Friday, 14 June 2019 15:19:50 PDT Lisandro Damián Nicanor Pérez Meyer 
wrote:
> On Fri, 14 Jun 2019 at 19:18, Lisandro Damián Nicanor Pérez Meyer
>  wrote:
> 
> [snip]
> 
> > The list of user-facing applications is much longer:
> > 
> > ls -1 `qmake -qt5 -query QT_INSTALL_BINS`
> 
> Sorry, that's the complete list of applications. We should still
> filter which ones should live in $libexecdir and which ones not.

I think they're all libexec except for:
 - qdbus
 - qdbusviewer
 - linguist
 - qmake
 - (possibly) qtdiag

The first three should promise backwards compatibility by design. The other 
two need to be suffixed.

I wonder if Assistant as a standalone application still makes sense. Is it 
used by the VS Add-in?

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

[Lisandro Damián Nicanor Pérez Meyer]

On Fri, 14 Jun 2019 at 19:18, Lisandro Damián Nicanor Pérez Meyer
 wrote:

[snip]
> The list of user-facing applications is much longer:
>
> ls -1 `qmake -qt5 -query QT_INSTALL_BINS`

Sorry, that's the complete list of applications. We should still
filter which ones should live in $libexecdir and which ones not.

-- 
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

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

[Lisandro Damián Nicanor Pérez Meyer]

Hi Matthew!

On Fri, 14 Jun 2019 at 18:36, Matthew Woehlke  wrote:
>
> On 14/06/2019 14.35, Lisandro Damián Nicanor Pérez Meyer wrote:
> > On Thu, 13 Jun 2019 at 17:02, Thiago Macieira wrote:
> >> That means you should NOT do that strong dependency. app5 should
> >> require qdbus >= Qt5, which means Qt 6's should suffice.>
> > Except you can't ship both version in the same binary-package,
>
> ...so? Pick one (and only one) to install.
>
> > so there is no way to express that relationship *with versioning*.
>
> Requires: qdbus >= 5.0  # satisfied by qdbus-6.3
>
> The whole point, as I understood it, was that the above is supposed to
> work. (If packagers aren't packaging qdbus separately, well, that's
> *their* problem.)

Correct, but that as long as the application is backwards compatible
and/or doesn't make use of external plugins (so far you shouldn't be
able to run a Qt4 plugin on a Qt5 designer). So far we have this
promise only with qdbus. The list of user-facing applications is much
longer:

ls -1 `qmake -qt5 -query QT_INSTALL_BINS`

> On 14/06/2019 15.05, Thiago Macieira wrote:
> > I was thinking that you'd split the package so that Qt 3, 4 and 5's
> > qdbus is never installed, but instead you always get the one from Qt
> > 6. That means Qt 6 is always installed in a system that needs qdbus,
> > regardless of whether any applications use it.
> That shouldn't be necessary. Just make "qdbus" a virtual package, and
> install the one for which you are willing to drag in Qt.
>
> i.e. qdbus5-5.13 → Provides: qdbus = 5.13
>
> (At this point, I'm talking about things *packagers* need to do. Qt can
> just ship /usr/bin/qdbus.)
>
> I'm not sure if package managers are smart enough to pick whichever
> concrete package satisfies a virtual dependency with the fewest
> dependencies of its own, but again, that's not *Qt's* problem.

And again, that's correct as long as we have the conditions I wrote
above. If they are don't met then yes, it becomes a Qt problem.


-- 
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

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

[Lisandro Damián Nicanor Pérez Meyer]

On Fri, 14 Jun 2019 at 16:06, Thiago Macieira  wrote:
>
> On Friday, 14 June 2019 11:35:20 PDT Lisandro Damián Nicanor Pérez Meyer
> wrote:
> > > That means you
> > > should NOT do that strong dependency. app5 should require qdbus >= Qt5,
> > > which means Qt 6's should suffice.
> >
> > Except you can't ship both version in the same binary-package, so
> > there is no way to express that relationship *with versioning*. The
> > package will need to depend upon qdbus (qt4) or qdbus-qt5. A virtual
> > package might be considered, but only for applications that will not
> > change their backwards behavior *ever*.
>
> THAT's a good point.
>
> I was thinking that you'd split the package so that Qt 3, 4 and 5's qdbus is
> never installed, but instead you always get the one from Qt 6. That means Qt 6
> is always installed in a system that needs qdbus, regardless of whether any
> applications use it.

And now I get your point here. I think we never thought in this
because qdbus is the only tool we have a promise of backwards
compatibility.

> This is not always a good solution.

But at the same time the only place in which this can not be good
would be in Yocto, but in those cases you will certainly ship only one
Qt version.

> But we should consider splitting qdbus and qdbusviewer out of qtbase and
> giving them their separate, independent releases.

That really sounds like a nice solution. I don't know if it uses
private headers or not. If it does it might need to be updated in case
a future revision breaks it, otherwise it should be quite
straightforward. And make Qt a little bit slimmer too.
___
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 14/06/2019 14.35, Lisandro Damián Nicanor Pérez Meyer wrote:
> On Thu, 13 Jun 2019 at 17:02, Thiago Macieira wrote:
>> That means you should NOT do that strong dependency. app5 should 
>> require qdbus >= Qt5, which means Qt 6's should suffice.>
> Except you can't ship both version in the same binary-package,

...so? Pick one (and only one) to install.

> so there is no way to express that relationship *with versioning*.

Requires: qdbus >= 5.0  # satisfied by qdbus-6.3

The whole point, as I understood it, was that the above is supposed to
work. (If packagers aren't packaging qdbus separately, well, that's
*their* problem.)

On 14/06/2019 15.05, Thiago Macieira wrote:
> I was thinking that you'd split the package so that Qt 3, 4 and 5's 
> qdbus is never installed, but instead you always get the one from Qt
> 6. That means Qt 6 is always installed in a system that needs qdbus,
> regardless of whether any applications use it.
That shouldn't be necessary. Just make "qdbus" a virtual package, and
install the one for which you are willing to drag in Qt.

i.e. qdbus5-5.13 → Provides: qdbus = 5.13

(At this point, I'm talking about things *packagers* need to do. Qt can
just ship /usr/bin/qdbus.)

I'm not sure if package managers are smart enough to pick whichever
concrete package satisfies a virtual dependency with the fewest
dependencies of its own, but again, that's not *Qt's* problem.

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

[Kevin Kofler]

Thiago Macieira wrote:
> But as you said, this is a developer tool. And interestingly, if we move
> the developer tools out of $PATH, qtchooser becomes an interesting
> solution to bring them back in for those few people who want them. So I
> don't see anything wrong with qtchooser as a developer-of-Qt tool.

This is exactly how Fedora ships qtchooser: It is not installed or used by 
default (the default setup relies on suffixed binaries in /usr/bin and 
unsuffixed binaries in a version-specific directory), but you can enable it 
by installing the qtchooser package and prepending its directory to your 
$PATH.

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 Friday, 14 June 2019 11:35:20 PDT Lisandro Damián Nicanor Pérez Meyer 
wrote:
> > That means you
> > should NOT do that strong dependency. app5 should require qdbus >= Qt5,
> > which means Qt 6's should suffice.
> 
> Except you can't ship both version in the same binary-package, so
> there is no way to express that relationship *with versioning*. The
> package will need to depend upon qdbus (qt4) or qdbus-qt5. A virtual
> package might be considered, but only for applications that will not
> change their backwards behavior *ever*.

THAT's a good point.

I was thinking that you'd split the package so that Qt 3, 4 and 5's qdbus is 
never installed, but instead you always get the one from Qt 6. That means Qt 6 
is always installed in a system that needs qdbus, regardless of whether any 
applications use it.

This is not always a good solution.

But we should consider splitting qdbus and qdbusviewer out of qtbase and 
giving them their separate, independent releases.

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

[Lisandro Damián Nicanor Pérez Meyer]

On Thu, 13 Jun 2019 at 17:02, Thiago Macieira  wrote:
>
> On Thursday, 13 June 2019 05:02:01 PDT Lisandro Damián Nicanor Pérez Meyer
> wrote:
> > > Giving our build tools different names depending on the version can create
> > > other problems for our users, especially those that use some hand rolled
> > > build systems (and we probably have lots of those as well).
> >
> > And the above is clearly a thing a Qt-internals' developer should definitely
> > look to, so a very valid concern. But let's take the other's too.
>
> I REALLY don't think there are a lot of hand-rolled buildsystems out there.
> And they must represent less than 0.1% of uses and complexity. We should
> consider giving them a solution. But by the same token, we should consider
> that Linux distributions must correspond to at least 10% of uses, which is
> 100x more.

That's my perception too, but I don't have data except maybe for some
partial data from linux distributions to back it up.

 it would be at very least amusing to have a guesstimate of
that, but I don't think that's feasible at all.

> > We can list qdbus and qdbusviewer as examples (perhaps not the best ones,
> > but will do for now). So let's say app4 is compiled against Qt4 (we still
> > have them around, sadly not every useful app was yet ported) and app5 is
> > compiled against Qt5. Take Qt 6 instead of Qt 4 if you like. Both where
> > developed using their own version's qdbus in mind.
> >
> > As a packager my duty is to ensure that app4 has a strong dependency against
> > Qt4's qdbus and app5 has a strong dependency against Qt5's qdbus, so both
> > versions of qdbus will be installed.
>
> Those are really not good examples because qdbus is a regular tool that
> retains compatibility going forward, > like any other tool.

Actually they are the worsts examples. Those are the only tools that
it's maintainer (you Thiago) publicly expressed that they will keep
compatibility when I asked about that back when qtchooser was a new
thing. For the rest, at least in my memory (anyone please feel free to
prove me wrong) no compatibility was promised nor denied.

> That means you
> should NOT do that strong dependency. app5 should require qdbus >= Qt5, which
> means Qt 6's should suffice.

Except you can't ship both version in the same binary-package, so
there is no way to express that relationship *with versioning*. The
package will need to depend upon qdbus (qt4) or qdbus-qt5. A virtual
package might be considered, but only for applications that will not
change their backwards behavior *ever*.

> The only other application that come close are Linguist and Assistant.

Ideally we should list all the applications and check whether they
really need to be in $libexec or directly accessible in $PATH, at very
least for the exercise of doing it.

> > ## Binaries that need to be accesible by developers using Qt
> >
> > These are moc, rcc, linguist, designer, uic, etc. Some of them really
> > need to be in
> > $libexecdir and ought to be found by way of the .cmake and .pc files
> > [1]. But then
> > there are the other tools that, once again, need to be readily accesible for
> > a developer user but in a much "normal" way. Let's say for example
> > linguist. Translators
> > are normally more in the "user" side of things than in the "developer" side.
> >
> > assistant might probably be in this situation too.
> >
> > [1]
> >  > ml> [2]
> >  > ml>
> >
> > And maybe lupdate is also an elegible example.
>
> The command-line tools used by the build system (moc, rcc, lupdate, etc.)
> should be in a lib / libexec dir and found by .cmake and .pc files.

As a start of the exercise I wrote above: should lupdate be in
$libexec? lupdate is normally used during string freeze. Granted, it
can be added as a non-automatic target of the build system, but it's
not strange at all to run it by hand. After all, is there any benefit
of running it during the build? Maybe there are some special cases,
but mostly it will regenerate a file that ought to be shipped with the
source code tarball, if shipped at all (I doubt proprietary apps/libs
would ship them).

Also, can we warrant that lupdate will *never* change it's default
output? Maybe we can for qt6, maybe it's a good time to change
something.

> For a
> foreign buildsystem, the only modification necessary is to change how it
> launches the binaries. Not very difficult and probably not the only
> modification necessary anyway to support Qt 6.

Agreed for stuff that can really live in $libexec.

> Linguist and Assistant are a different story: they should be found by the
> desktop menu. Both should retain compatibility with old files and, in case of
> Linguist, *generate* for older formats so the same tool can be used to
> translate for Qt 3, 4, 5 and 6.

Just as long as this can be achieved/supported as a P1 bug 

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

[Thiago Macieira]

On Thursday, 13 June 2019 05:02:01 PDT Lisandro Damián Nicanor Pérez Meyer 
wrote:
> > Giving our build tools different names depending on the version can create
> > other problems for our users, especially those that use some hand rolled
> > build systems (and we probably have lots of those as well).
> 
> And the above is clearly a thing a Qt-internals' developer should definitely
> look to, so a very valid concern. But let's take the other's too.

I REALLY don't think there are a lot of hand-rolled buildsystems out there. 
And they must represent less than 0.1% of uses and complexity. We should 
consider giving them a solution. But by the same token, we should consider 
that Linux distributions must correspond to at least 10% of uses, which is 
100x more.

> We can list qdbus and qdbusviewer as examples (perhaps not the best ones,
> but will do for now). So let's say app4 is compiled against Qt4 (we still
> have them around, sadly not every useful app was yet ported) and app5 is
> compiled against Qt5. Take Qt 6 instead of Qt 4 if you like. Both where
> developed using their own version's qdbus in mind.
> 
> As a packager my duty is to ensure that app4 has a strong dependency against
> Qt4's qdbus and app5 has a strong dependency against Qt5's qdbus, so both
> versions of qdbus will be installed.

Those are really not good examples because qdbus is a regular tool that 
retains compatibility going forward, like any other tool. That means you 
should NOT do that strong dependency. app5 should require qdbus >= Qt5, which 
means Qt 6's should suffice.

The only other application that come close are Linguist and Assistant.

> ## Binaries that need to be accesible by developers using Qt
> 
> These are moc, rcc, linguist, designer, uic, etc. Some of them really
> need to be in
> $libexecdir and ought to be found by way of the .cmake and .pc files
> [1]. But then
> there are the other tools that, once again, need to be readily accesible for
> a developer user but in a much "normal" way. Let's say for example
> linguist. Translators
> are normally more in the "user" side of things than in the "developer" side.
> 
> assistant might probably be in this situation too.
> 
> [1]
>  ml> [2]
>  ml>
> 
> And maybe lupdate is also an elegible example.

The command-line tools used by the build system (moc, rcc, lupdate, etc.) 
should be in a lib / libexec dir and found by .cmake and .pc files. For a 
foreign buildsystem, the only modification necessary is to change how it 
launches the binaries. Not very difficult and probably not the only 
modification necessary anyway to support Qt 6.

Linguist and Assistant are a different story: they should be found by the 
desktop menu. Both should retain compatibility with old files and, in case of 
Linguist, *generate* for older formats so the same tool can be used to 
translate for Qt 3, 4, 5 and 6. Assistant is even worse because it's meant to 
be launched by applications...

That's different from Designer.

> # Seeing the problem as a Qt-internal's developer
> 
> I can see value in qtchooser for Qt-internal's developers. You can easily
> switch between Qt versions without too much hassle.

Not just versions, even different builds of the same version. For the past 7 
years, ever since I dropped the 4.8 build, I've only had a single Qt version 
built. It's built multiple times, with different compilers and options, but 
it's still the same version.

But as you said, this is a developer tool. And interestingly, if we move the 
developer tools out of $PATH, qtchooser becomes an interesting solution to 
bring them back in for those few people who want them. So I don't see anything 
wrong with qtchooser as a developer-of-Qt tool.

As a developer-using-Qt, I need to be able to install several Qt in parallel 
so I can test my application with them, but this is going to depend on which 
buildsystem I chose for my application. If I'm using qmake, qtchooser is 
interesting, but people already know to type the full path if they downloaded 
from qt.io anyway. If I'm using CMake, then I need to set some environment 
variable so CMake knows where to find the .cmake files -- this isn't solved by 
qtchooser, but by a wrapping shell function.

Additionally, I may want to run a few debugging helpers, like qtplugininfo or 
qtdiag.

> I sincerely do not know how you manage to keep up with your desktop
> environment in Linux as I'm pretty sure most of you are not using a
> GTK-based desktop :-) Why I say that? because even the smallest Qt-based
> desktop environment ships theming which requires using Qt's private API, so
> it's tightly tied to a specific ¡minor! version. And I'm pretty sure there
> are other cases which have the same issue.

My Linux desktop uses the distro-provided Qt. My own builds use a lib infix so 
that no system application 

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

[Thiago Macieira]

On Thursday, 13 June 2019 01:06:06 PDT Bogdan Vatra via Development wrote:
> Hi,
> 
>   There is one more missing feature to add to your list: build & debug
> builds for msvc in one go (same as qmake does now, a single "make" command
> will build both targets).

I wouldn't call that a hard requirement. Separate builds for debug and for 
release are acceptable, the same way that we've ostensibly had support for 
shared-and-release builds but in practice they're always built separately.

The only difficult part I see is enforcing the suffix. On Mac we've had 
problems with this, since a debug-only build is un-suffixed. Maybe it's time 
to rethink the strategy and make the suffix optional altogether (using the lib 
infix feature). On Windows, we should stop enforcing that unoptimised builds 
be -MDd and make it easy for people to debug into -MD libraries. Hardly anyone 
ever debugs into Microsoft's libraries...

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

2 years in the wild was not for all features, it was for the buildsystem 
itself and the major features. But we need to build with the version that 
comes with the host systems that we are targetting (if they ship tools like 
this in the first place; Windows doesn't).

That means that the iOS support only needs to be present in whatever version 
of CMake that Homebrew installs. Since Homebrew always has the latest, this is 
not an impediment.

But if we want to build on Ubuntu 16.04, then that three year old version's 
CMake needs to be sufficient for a native build of Qt and whatever cross-
builds get targeted from Linux (Android and QNX, I'd guess). For Qt 6, I'd 
just recommend raising the minimum to 18.04...

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

[Lisandro Damián Nicanor Pérez Meyer]

Resending because I mistakenly replied just to Lars.

Lars: thansk for the heads up, and also note I rewrote a paragraph below,
hopefully to be more on point.

On 19/06/11 07:12, Lars Knoll wrote:
> Hi Lisandro,

Hi Lars!

[snip]
> That thread doesn’t explain why qtchooser isn’t a solution. It does work
> without problems for all my use cases, and I certainly do have quite a few Qt
> versions installed in parallel.

Maybe my fault, I have discussed this in this mailing list before. The mail
also has a link to our bugs list, but let me try to write down it's pros
and cons here.

> Part of the problem simply stems from the fact that Linux distributions
> want to put all the binaries into /usr/bin. As long as you keep separate
> Qt versions in separate directories there’s no problem I know of.

Each operative system has it's design rules. We might or not like them, but if
we want Qt to be really a multi-platform code-once tool then we should accept
those rules and do our best to build upon them.

Let's try to put this into two three different points of view:

- A Qt-internals' developer
- A developer using Qt to create stuff
- A system developer/integrator (within this, distro maintainers).

> Giving our build tools different names depending on the version can create
> other problems for our users, especially those that use some hand rolled
> build systems (and we probably have lots of those as well).

And the above is clearly a thing a Qt-internals' developer should definitely
look to, so a very valid concern. But let's take the other's too.

I am taking maybe another approach to what Kevin already wrote in [a], but I do
agree to what he wrote there too.

[a] 

# Problem 1: binary masking

At first I thought qtchooser might probe to be a nice tool for switching
versions much like Shawn wrote, but then experience showed us the contrary.

With "binary masking" I mean that qtchooser replaces the path for where a
binary should be with itself.

With this comes the following cases:

## Binaries that need to be accesible by "the user"

This are the ones that really need to be in $PATH because the normal user needs
it. We can't expect a normal user to add to $PATH a "weird" path of a specific
Qt version and change it every time it needs to switch versions. Let's add that
the user of that application might well be another application or
system library.

We can list qdbus and qdbusviewer as examples (perhaps not the best ones, but
will do for now). So let's say app4 is compiled against Qt4 (we still have
them around, sadly not every useful app was yet ported) and app5 is compiled
against Qt5. Take Qt 6 instead of Qt 4 if you like. Both where developed using
their own version's qdbus in mind.

As a packager my duty is to ensure that app4 has a strong dependency against
Qt4's qdbus and app5 has a strong dependency against Qt5's qdbus, so both
versions of qdbus will be installed.

Now both app4 and app5 developer's will probably not worry about qtchooser
because it's just a hack needed on Linux, so they won't be calling 'qdbus -qt5'
(which, as Kevin said, it's not even a standard) but just 'qdbus'. So with
qtchooser around app4 and app5 will receive both the same version of qdbus, be
it Qt 4's or 5's.

So, why it has not backfired yet? Because thanks Thiago (probably) qdbus behaves
the same in both Qt 4 and 5. Had they differed in the way they behave... kaboom.
We packagers would be probably needed to start patching applications to pass
proper qtchooser arguments, which is not something developers that use Qt like a
lot.

So the big question here is: can we *really* keep this applications
backward-compatible for the whole Qt 4, 5 and 6 and future versions?

## Binaries that need to be accesible by developers using Qt

These are moc, rcc, linguist, designer, uic, etc. Some of them really
need to be in
$libexecdir and ought to be found by way of the .cmake and .pc files
[1]. But then
there are the other tools that, once again, need to be readily accesible for a
developer user but in a much "normal" way. Let's say for example
linguist. Translators
are normally more in the "user" side of things than in the "developer" side.

assistant might probably be in this situation too.

[1] 

[2] 


And maybe lupdate is also an elegible example.

## Binary masking and dependency resolution

Now the user installs qt5's qdbus. Currently that will in turn install
qtchooser (there is currently no way around it except renaming binaries),
so /usr/bin/qdbus is taken.

Now the user needs qt5's qdbus, so he simply runs 'qdbus'. It will fail. Why is
that? Because in Qt 4 the concept of qtchooser did not exist, so the
default system
consiguration needs to be qt4 as long as there is any piece of it installed on
the 

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

[Bogdan Vatra via Development]

Hi,

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

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

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

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

Cheers,
BogDan.


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



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

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

[Lars Knoll]

Hi all,

After all the discussion, lets go back to the original proposal. We can see 
from the discussions that there is still work to be done, but I can’t find 
anything that sounds like a real showstopper.

The two missing features that were voiced as a concern (if I didn’t miss 
anything in the thread) where multi arch/fat binary support for iOS and PCH 
support. I also heard that the people working on it are confident they can get 
this fixed in time for Qt 6, something I’m happy with for now. Nevertheless, I 
think it would be good if the team working on the cmake port could summarise 
how/when they are planning to fix this.

One additional concern was multi arch builds for Android, but I don’t think 
that counts as a concern as qmake does not support this neither (so it would be 
a new feature).

Finally, there was a concern around qmake support for users of Qt. This is 
something I have discussed with the team in the past, and it is a strong 
requirement that qmake will continue working as a build system for our users at 
least for the foreseeable future. This can and will be solved by cmake creating 
the required files to support qmake. Btw, this is also a hard requirement to be 
able to change build system repository by repository, so that we don’t have to 
do a all or nothing switch of all our repos.

In summary, I do agree with and support the initial proposal by Simon to merge 
wip/cmake into wip/qt6.

Cheers,
Lars

> On 6 Jun 2019, at 14:43, Sérgio Martins  wrote:
> 
> On Thu, Jun 6, 2019 at 12:45 PM Simon Hausmann  wrote:
>> 
>> Hi,
>> 
>> In the past months we, some developers from the Qt Company and KDAB,
>> have made good progress on the port of Qt to use CMake as build tool.
> 
> +1, simply because we only have 1 contender so far.
> 
> Thanks for stepping up and doing the work.
> 
> Regards,
> Sérgio Martins
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development

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

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

[Simon Hausmann]

Am 12.06.19 um 12:45 schrieb Christian Gagneraud:
> On Fri, 7 Jun 2019 at 03:31, Alexandru Croitor  
> wrote:
>> On 6. Jun 2019, at 16:48, Christian Gagneraud  wrote:
>> 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
>>  wrote:
> [what a beautiful thread, flatten by HTML top posting where no one can
> understand the history of this discussion]
>
>> What metrics do you expect?
>> With the time I had available, I discovered some issues regarding iOS + 
>> CMake, but nothing insurmountable.
>> I gave my analysis. We (people working on the CMake port) feel it's possible 
>> to do.
>> Now it's just a matter of getting to do it. But we still have other things 
>> to do first.
> BTW, can cmake "out of the box" deal with:
> https://doc.qt.io/qt-5/qtremoteobjects-repc.html
> https://doc.qt.io/QtQuickCompiler/
> https://doc.qt.io/qtforpython/shiboken2/shibokenmodule.html
>
> Last time i checked none of these were supported.


QtRemoteObjects has come with CMake support since its initial release 
with Qt 5.9.0. According to git log, Kevin Funk implemented it.

The QtQuickCompiler has come with CMake support since version 2.0 
released in 2014. The git history for that is not public, but I know it 
because I wrote it myself.

Qt For Python uses CMake as its build system and it supports running 
shiboken from your project to generate type information and bindings. 
It's not very convenient from what I can tell, but it works. The docs 
are referring to it here


https://doc.qt.io/qtforpython/shiboken2/samplebinding.html#building


and the actual code is located in the pyside-setup repository under 
examples.


> Yes, qmake support is "hackish", but that is not a good reason to
> justify the near-zero support of cmake.


The above at least is certainly not "near-zero".


> And let me diverge a little bit, whatever the build system chosen by
> Qt *developers*,  Qt *users* should still be free to choose their own
> build system. I'm including both open source users and paid customers.
> That is: however *you* (qt developers) decide to use as your build
> system shouldn't impact what *I* (as a Qt user) decide to use as my
> own build system.
> For example, you'll have to support qmake for years to come... You
> like it or not.


I tend to agree with that. At the moment this is primarily a decision 
for Qt development itself.


Simon

___
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 Fri, 7 Jun 2019 at 03:31, Alexandru Croitor  wrote:
> On 6. Jun 2019, at 16:48, Christian Gagneraud  wrote:
> 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
>  wrote:

[what a beautiful thread, flatten by HTML top posting where no one can
understand the history of this discussion]

> What metrics do you expect?
> With the time I had available, I discovered some issues regarding iOS + 
> CMake, but nothing insurmountable.
> I gave my analysis. We (people working on the CMake port) feel it's possible 
> to do.
> Now it's just a matter of getting to do it. But we still have other things to 
> do first.

BTW, can cmake "out of the box" deal with:
https://doc.qt.io/qt-5/qtremoteobjects-repc.html
https://doc.qt.io/QtQuickCompiler/
https://doc.qt.io/qtforpython/shiboken2/shibokenmodule.html

Last time i checked none of these were supported.

Yes, qmake support is "hackish", but that is not a good reason to
justify the near-zero support of cmake.

And let me diverge a little bit, whatever the build system chosen by
Qt *developers*,  Qt *users* should still be free to choose their own
build system. I'm including both open source users and paid customers.
That is: however *you* (qt developers) decide to use as your build
system shouldn't impact what *I* (as a Qt user) decide to use as my
own build system.
For example, you'll have to support qmake for years to come... You
like it or not.

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]

Even if modules were available (and stable) in at least mainline versions
of {clang, gcc, msvc} in a year (which I don't think they will), Qt would
have to get modularized to actually be able to reap the benefits of modules
(given the strong feelings in the "deprecations" thread, we can expect
mid-2050 for that one maybe ? e.g. for now Qt 6 will be AFAIK on a C++17
baseline... if we consider that it took up to Qt 5.7, released in 2016, to
require a C++11 compiler to build, you can see that `import QString;` in
qobject.h is still a decade away :-)).

So I really think that the time saved by PCH today, which is for me at
least a good few minutes per Qt build, is important to keep.
Besides, current implementations of modules aren't faster than a good PCH
(or at least they weren't last time I checked clang's).

Best,
Jean-Michaël

On Tue, Jun 11, 2019 at 5:50 PM Matthew Woehlke 
wrote:

> On 06/06/2019 09.23, Simon Hausmann wrote:
> > 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.
>
> Considering that modules are coming, I wonder how much sense it makes to
> keep working on PCH?
>
> --
> Matthew
> ___
> 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

[Matthew Woehlke]

On 06/06/2019 09.23, Simon Hausmann wrote:
> 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.

Considering that modules are coming, I wonder how much sense it makes to
keep working on PCH?

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

[Kevin Kofler]

Shawn Rutledge wrote:
> I do think qtchooser could be a generalized portable utility, not just for
> Qt.  But switching versions by updating symlinks (as in the
> /etc/alternatives system) is relatively clumsy compared to the way
> qtchooser lets you switch to different versions in each shell instance if
> you like.

/etc/alternatives is not the proper solution either. It has mostly the same 
design flaws as qtchooser, with the additional issue that the choice is a 
global systemwide choice rather than a runtime one, which breaks multi-user 
setups and concurrency (can't build apps against different Qt versions 
concurrently).

The correct solution is to use unique (i.e., in practice, suffixed) binary 
names.

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

[Kevin Kofler]

Lars Knoll wrote:
> That thread doesn’t explain why qtchooser isn’t a solution. It does work
> without problems for all my use cases, and I certainly do have quite a few
> Qt versions installed in parallel.

There are 4 crucial design flaws that make qtchooser unsuitable for 
distributions:
1. The choice of preferred Qt version is a user configuration. It should be
   a configuration set by the build system of the program being built. The
   program should know what Qt version(s) it supports. I should not have to
   configure the version to use before I compile something. This can be
   worked around by explicitly passing the -qt option in the build system,
   but that leads us to:
2. The build system has no portable way to know whether the binaries it is
   about to run are wrapped by qtchooser or raw binaries. If it tries
   passing qtchooser options to the raw binaries, it will likely get an
   error (and catching that error is the only way to know for sure). Even if
   the raw binaries get "fixed" to ignore qtchooser options, that will not
   solve the issue for all the old raw binaries around. (If you call
   unsuffixed binaries on Fedora, you will likely get Qt 3 ones.)
3. The names or numbers that can be used with -qt are not standardized.
   Something like -qt5 will likely work in almost all qtchooser setups.
   Something like -qt5.12 or -qt5_64bit may or may not work. This also
   limits the usefulness for automatic use in build systems or scripts.
4. The build system has to actually run the qtchooser wrappers to know what
   Qt version(s) is/are installed (and then try to actually understand the
   returned list, see point 3 above), not just check for file existence.

In contrast, with suffixed binaries (e.g., qmake-qt5):
1. The build system decides whether to run qmake-qt5 or qmake-qt6 (and those
   should always be tried BEFORE unsuffixed qmake, which is likely the
   oldest version that the distro still supports and can be as old as Qt 3!
   Ideally, Qt upstream would finally standardize on suffixing for Qt 6 and
   so unsuffixed qmake wouldn't have to be tried at all anymore).
2. The build system always gets to run the real binaries (and does not have
   to rely on wrapper options to get the correct binary).
3. The suffix should be standardized by the upstream installation (i.e.,
   make install should install the tools with that suffix). The de facto
   standard suffixes of the form "-qt5" (used in several distributions)
   should be adopted. If ABI breaks in minor releases are needed (which I
   still think is a horrible idea), then the suffix needs to be changed to
   something like "-qt6.3", e.g., "qmake-qt6.3".
4. The build system only has to check whether qmake-qt6 exists to know
   whether Qt 6 is installed, it does not have to actually run anything.

So the suffixed binaries are the far superior approach.

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

[Shawn Rutledge]

> On 11 Jun 2019, at 09:12, Lars Knoll  wrote:
> 
> That thread doesn’t explain why qtchooser isn’t a solution. It does work 
> without problems for all my use cases, and I certainly do have quite a few Qt 
> versions installed in parallel.
> 
> Part of the problem simply stems from the fact that Linux distributions want 
> to put all the binaries into /usr/bin. As long as you keep separate Qt 
> versions in separate directories there’s no problem I know of. Giving our 
> build tools different names depending on the version can create other 
> problems for our users, especially those that use some hand rolled build 
> systems (and we probably have lots of those as well).

I also use qtchooser and miss the days when Arch used to provide a package for 
it, and also the qtchooser config file along with Qt, so that it was easy to 
manage multiple Qt versions out of the box.  Switching between Qt4 and Qt5 was 
a breeze too.  Unfortunately they decided that it’s bad for regular users: 
https://bugs.archlinux.org/task/51308  I work around it by building qtchooser 
myself and installing to ~/bin (which I have early enough in my shell path to 
be able to override system binaries with a few of my own).  The same trick 
works on macOS too, BTW.  Brew doesn’t provide qtchooser either, you have to 
build it yourself.  I even use mostly the same config files on both Linux and 
macOS (~/.config/qtchooser/5dd.conf is always a debug build on dev branch for 
example, and in my shell I type “qt 5dd” to switch to that version), because ~ 
is the home directory even though it’s in a different place on macOS.  I have 
my config files in my dotfiles git repo and keep them synced between machines 
that way.  (You could use syncthing, also highly recommended.)

I do think qtchooser could be a generalized portable utility, not just for Qt.  
But switching versions by updating symlinks (as in the /etc/alternatives 
system) is relatively clumsy compared to the way qtchooser lets you switch to 
different versions in each shell instance if you like.

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

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

[Lars Knoll]

Hi Lisandro,

On 9 Jun 2019, at 16:46, Lisandro Damián Nicanor Pérez Meyer 
mailto:perezme...@gmail.com>> wrote:

Hi Simon!

On Thu, 6 Jun 2019 at 08:46, Simon Hausmann 
mailto:simon.hausm...@qt.io>> 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 summarized roughly like this:

Does the port take into consideration the renaming of tooling to allow
easier co installation of Qt 5 and Qt 6? As discussed in
https://lists.qt-project.org/pipermail/development/2018-November/034381.html

That thread doesn’t explain why qtchooser isn’t a solution. It does work 
without problems for all my use cases, and I certainly do have quite a few Qt 
versions installed in parallel.

Part of the problem simply stems from the fact that Linux distributions want to 
put all the binaries into /usr/bin. As long as you keep separate Qt versions in 
separate directories there’s no problem I know of. Giving our build tools 
different names depending on the version can create other problems for our 
users, especially those that use some hand rolled build systems (and we 
probably have lots of those as well).

Cheers,
Lars

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

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

[Lisandro Damián Nicanor Pérez Meyer]

Hi Simon!

On Thu, 6 Jun 2019 at 08: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 summarized roughly like this:

Does the port take into consideration the renaming of tooling to allow
easier co installation of Qt 5 and Qt 6? As discussed in
https://lists.qt-project.org/pipermail/development/2018-November/034381.html

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

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

[Simon Hausmann]

Hi,

I don't think anybody has tried an emscripten build yet. That said, from a 
building perspective it's a regular static build of Qt, emscripten comes with a 
cmake toolchain file, it's a single arch build and generally an easy interface, 
in my experience working with emscripten. The main issue that I can forsee at 
this point is the third-party library dependency handling, which works slightly 
differently and the missing PCRE2 in emscripten ports.



Simon

From: Development  on behalf of Michael 
Winkelmann 
Sent: Thursday, June 6, 2019 19:19
To: development@qt-project.org
Subject: Re: [Development] Proposing CMake as build tool for Qt 6

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 well and its
> current state can be summarized roughly like this:
>
> * Builds on
>   * Windows (desktop)
>   * macOS
>   * Linux (desktop and embedded)
>   * Android (running not tested yet)
>
> * Static builds and plugins are implemented.
>
> * Many examples and tests are compiling and running.
>
> * Several modules outside of qtbase have been ported as well,
>   including qtsvg, qtimageformats, qnetworkauth as well as parts of
>   qtdeclarative.
>
> * There are early-warning style CI builds (no tests) running and
>   reporting results to patches uploaded to Gerrit.
>
> * There is tooling in-place to re-generate cmake files from
>   .pro/configure.json files, providing a method of dealing with the
>   long term maintenance of merging from qmake based Qt (5) branches.
>
> * Very basic support for compiling applications (not modules) with qmake
>   against a CMake built Qt.
>
> Many of the more fine-grained details are tracked in JIRA under an Epic:
>
> https://bugreports.qt.io/browse/QTBUG-73351
>
> as well as in the Qt Project Wiki at
>
> https://wiki.qt.io/CMake_Port
>
> Detailed steps on how to build Qt with CMake are available at
>
>https://code.qt.io/cgit/qt/qtbase.git/tree/cmake/README.md?h=wip/cmake
>
> There are some caveats with the above as well, but overall we feel confident
> about it. Therefore we would like to propose CMake as the build tool for
> Qt 6
> and would like to achieve a decision within the Qt project by lazy
> consensus.
>
> For the decision making it is important to also lay out the proposed path
> forward. We would like to merge the wip/cmake branch(es) into the wip/qt6
> branch of qtbase and other applicable repositories. This would pave the way
> for a transition that could look like this:
>
> (1) The CMake build system related files and scripts become visible
> to Qt 6 development. Both build systems co-exist.
>
> (2) The wip/qt6 branches continue to be built using qmake in the CI
> until we are ready to switch.
>
> (3) When the corresponding changes in Coin and qtbase are ready, a
> new configuration file in qtbase would switch the qtbase build over
> to use cmake for some configurations.
>
> (4) Through iteration all configurations are changed to use cmake.
>
> (5) The .pro/.pri files of projects can be removed -- the qmake
> sources themselves as well as mkspecs/features (and potentially
> other files) remain.
>
>
> We are looking forward to a productive discussion and feedback.
>
>
> Simon
>
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
>

--
---
Michael Winkelmann
Qt Advisor

The Qt Company GmbH
Rudower Chaussee 13
D-12489 Berlin
michael.winkelm...@qt.io
+4915122973404
http://qt.io

Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht
Charlottenburg, HRB 144331 B
---
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

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

[Michael Winkelmann]

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 well and its
> current state can be summarized roughly like this:
> 
>     * Builds on
>       * Windows (desktop)
>       * macOS
>       * Linux (desktop and embedded)
>       * Android (running not tested yet)
> 
>     * Static builds and plugins are implemented.
> 
>     * Many examples and tests are compiling and running.
> 
>     * Several modules outside of qtbase have been ported as well,
>       including qtsvg, qtimageformats, qnetworkauth as well as parts of
>       qtdeclarative.
> 
>     * There are early-warning style CI builds (no tests) running and
>       reporting results to patches uploaded to Gerrit.
> 
>     * There is tooling in-place to re-generate cmake files from
>       .pro/configure.json files, providing a method of dealing with the
>       long term maintenance of merging from qmake based Qt (5) branches.
> 
>     * Very basic support for compiling applications (not modules) with qmake
>       against a CMake built Qt.
> 
> Many of the more fine-grained details are tracked in JIRA under an Epic:
> 
>     https://bugreports.qt.io/browse/QTBUG-73351
> 
> as well as in the Qt Project Wiki at
> 
>     https://wiki.qt.io/CMake_Port
> 
> Detailed steps on how to build Qt with CMake are available at
> 
>    https://code.qt.io/cgit/qt/qtbase.git/tree/cmake/README.md?h=wip/cmake
> 
> There are some caveats with the above as well, but overall we feel confident
> about it. Therefore we would like to propose CMake as the build tool for
> Qt 6
> and would like to achieve a decision within the Qt project by lazy
> consensus.
> 
> For the decision making it is important to also lay out the proposed path
> forward. We would like to merge the wip/cmake branch(es) into the wip/qt6
> branch of qtbase and other applicable repositories. This would pave the way
> for a transition that could look like this:
> 
>     (1) The CMake build system related files and scripts become visible
>     to Qt 6 development. Both build systems co-exist.
> 
>     (2) The wip/qt6 branches continue to be built using qmake in the CI
>     until we are ready to switch.
> 
>     (3) When the corresponding changes in Coin and qtbase are ready, a
>     new configuration file in qtbase would switch the qtbase build over
>     to use cmake for some configurations.
> 
>     (4) Through iteration all configurations are changed to use cmake.
> 
>     (5) The .pro/.pri files of projects can be removed -- the qmake
>     sources themselves as well as mkspecs/features (and potentially
>     other files) remain.
> 
> 
> We are looking forward to a productive discussion and feedback.
> 
> 
> Simon
> 
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
> 

-- 
---
Michael Winkelmann
Qt Advisor

The Qt Company GmbH
Rudower Chaussee 13
D-12489 Berlin
michael.winkelm...@qt.io
+4915122973404
http://qt.io

Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht
Charlottenburg, HRB 144331 B
---
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

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

[Thiago Macieira]

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 toolchain file. The embedded Linux case was against a Yocto SDK.

Good, thanks, that's what I figured but needed to confirm.

Have you tried to compile Qt as *part* of the Yocto Project build? To be 
honest, that's what people making devices should be doing, not using an SDK 
created by the build.

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

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):   current ar archive
lib/libQt5Core_debug.a (for architecture x86_64h):  current ar archive

It fails a bit further in a tool, but that's because my double conversion 
library only has one architecture slice.

So it should work in principle.

> On 6. Jun 2019, at 17:59, Thiago Macieira  wrote:
> 
> 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 (AT) intel.com
>  Software Architect - Intel System Software Products
> 
> 
> 
> ___
> 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

[Simon Hausmann]

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.


Simon

> On 6. Jun 2019, at 17:54, Thiago Macieira  wrote:
> 
>> 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 Aaron Seigo trying to compile Plasma on an N900 during a meet up 
> and 
> waiting for a week for it to complete?
> 
> Anyway, can you add a report on the ability to cross-compile?
> 
> -- 
> 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
___
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 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 (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 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 Aaron Seigo trying to compile Plasma on an N900 during a meet up and 
waiting for a week for it to complete?

Anyway, can you add a report on the ability to cross-compile?

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

Am 06.06.19 um 15:52 schrieb Christian Gagneraud:
On Fri, 7 Jun 2019 at 01:35, Bogdan Vatra via Development
mailto:development@qt-project.org>> 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 cmake support will be poor or non existing.
IOs, Android (and other upcoming OS [1]) multi-arch  builds are IMHO a
hard-requirement.
Since when the build system "candidate" dictates Qt supported platform?
I thought it was supposed to be the other way around.

And now people are calling for "community" help b/c they realise that
it will take a massive effort to support these requirements.

FWIW, I didn't say that without support from the community nothing will
happen, which is what you're suggesting. Eventually somebody from the Qt
Company is likely going to dig into the particular topic of iOS, for
example. If you would like to see something implemented before that
point in time, then please join the development effort. We also hang out
in #qt-cmake on Freenode, btw.
That's exactly my point, "you" took the decision before analysing the
problems, and now you're asking me to join #qt-cmake to make it
happen!?! Why would i do that? Can't you provide something that works?
If not, please bail out.

As you can see from the responses, an analysis on CMake and iOS has been
done, with encouraging results. These results, on conjunction with the

No, an analisys wasn't done *prior*, an analysis of the problems is
*currently* being done.
That's my feeling right now.
None of these was mentioned in your original email.

If you read my previously sent email, I mention that the investigation was done 
around 2 months ago, and not *currently*.
Yes, Simon's initial email did not contain information regarding iOS, but mine 
did.
Simon did not have all the details, because it was not him that looked into it.


results in the other platforms/configurations, gave us - some TqTC and
KDAB devs - enough confidence that we think that we can pull it off. I

So you're basically saying  that you have no real metrics, just gut
feeling that it is possibly doable.
Please bring facts, not gut feelings.

What metrics do you expect?
With the time I had available, I discovered some issues regarding iOS + CMake, 
but nothing insurmountable.
I gave my analysis. We (people working on the CMake port) feel it's possible to 
do.
Now it's just a matter of getting to do it. But we still have other things to 
do first.



did not ask you to join to make it happen, please don't put words into
my mouth. I said that if you'd like to see something implemented before
we get to it, then you're invited to join the effort.

Stop saying that i put words in your mouth, i'm just reading and
interpreting what you're saying.
And right now, i've been heavily invited to something that i don't
want to join. Period.

Please stop making promises based on potential future "community
contribution" that you cannot guarantee.
We need facts, not promises and futures.

Can you multi-arch-build a Qt example/tutorial for Ios/Android right now?

Correct me if I'm wrong, but qmake does not support multi-arch builds for 
Android either. We provide separate packages for separate architecture.  So 
both CMake and qmake are the same in this regard.

We can not currently build fat libraries containing simulator + device 
architectures with CMake in one compiler invocation, like it is done with 
qmake. That needs to be fixed in CMake first. This does not mean it is 
impossible. And it does not mean that it will not be done.

Fat libraries with multiple arches for only simulator (x86 + x64), or only 
devices (arm 32 + arm64) works.


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

[Christian Gagneraud]

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 summarized roughly like this:

Am I the only one to notice that this thread is just made of HTML
top-posting messages? [1]

Just sayin'

Chris

[1] https://en.wikipedia.org/wiki/Etiquette_in_technology#Netiquette
___
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]

> 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 (man cmake-buildsystem).
Also multiple IDEs can integrate with CMake's documentation nowadays :
QtCreator (the doc being available in QtHelp format :
https://cmake.org/documentation/), Visual Studio (
https://devblogs.microsoft.com/cppblog/in-editor-documentation-for-cmake-in-visual-studio/).
..
It's pretty nice to be able to do F1 in target_whatever_foobar in QtCreator
and get the relevant help shown :-)

Best,
Jean-Michaël



On Thu, Jun 6, 2019 at 4:42 PM Palaraja, Kavindra 
wrote:

> 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 definitely be necessary.
>
>
>
> Regards,
>
> Kavindra.
>
>
>
> *From: *Simon Hausmann 
> *Date: *Thursday, 6. June 2019 at 16:02
> *To: *"Palaraja, Kavindra" , "
> development@qt-project.org" 
> *Subject: *Re: [Development] Proposing CMake as build tool for Qt 6
>
>
>
> 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 developers and correctly also refers to
> CMake's own manual at
>
>
>
> https://cmake.org/documentation/
>
>
>
> It might make sense to make that a more concrete link to the exactly
> version of CMake that Qt requires at the least. What do you think?
>
>
>
> This page might also benefit from a section or sub-page that provides help
> for qmake users on how to transition to CMake.
>
>
>
> Finally, the existing documentation about how to build Qt from source --
> https://doc.qt.io/qt-5/build-sources.html -- will require changes. It is
> our intention (or at least mine ;-) to transition the internal docs that
> address that, currently located at cmake/README.md, to those pages. We have
> not yet achieved the desired degree of convenience for building Qt with
> CMake though, and we have not reached the target branch yet. But once in
> wip/qt6 I think it might make sense to move things across.
>
>
>
>
>
>
>
> Simon
>
>
>
>
> --
>
> *From:* Development  on behalf of
> Palaraja, Kavindra 
> *Sent:* Thursday, June 6, 2019 15:37
> *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 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/Undocumented_QMake and
> such.
>
>
>
> --
>
> Kavindra.
>
>
>
> *From: *Development  on behalf of
> Simon Hausmann 
> *Date: *Thursday, 6. June 2019 at 13:46
> *To: *"development@qt-project.org" 
> *Subject: *[Development] Proposing CMake as build tool for Qt 6
>
>
>
> Hi,
>
>
>
> In the past months we, some developers from the Qt Company and KDAB,
>
> have made good progress on the port of Qt to use CMake as build tool.
>
> Since the initial prototype, the port has advanced very well and its
>
> current state can be summarized roughly like this:
>
>
>
> * Builds on
>
>   * Windows (desktop)
>
>   * macOS
>
>   * Linux (desktop and embedded)
>
>   * Android (running not tested yet)
>
>
>
> * Static builds and plugins are implemented.
>
>
>
> * Many examples and tests are compiling and running.
>
>
>
> * Several modules outside of qtbase have been ported as well,
>
>   including qtsvg, qtimageformats, qnetworkauth as well as parts of
>
>   qtdeclarative.
>
>
>
> * There are early-warning style CI builds (no tests) running and
>
>   reporting results to patches uploaded to Gerrit.
>
>
>
> * There is tooling in-place to re-generate cmake files from
>
>   .pro/con