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

[Lorn Potter]

On 9/6/20 11:23 PM, Alexandru Croitor wrote:

- WebAssembly completely lost

That is true. As I mentioned in my reply to Andre, we tested it at some point, 
but we don't have current plans to add it to the CI.



I would be surprised if it actually built, as emscripten compiler for Qt 
WebAssembly needs special linker flags (beyond what is in the toolchain 
file), as well as in the platform app build, we move files and sed 
replace strings to make it all work.


I spent an hour or so today trying to get dev branch built for 
webassembly using cmake, and could not get past the initial cmake call.



--
Lorn Potter
Freelance Qt Developer. Maintainer QtSensors, Qt WebAssembly

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

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

[Thiago Macieira]

On Tuesday, 9 June 2020 01:26:12 PDT Alexandru Croitor wrote:
> > On 9. Jun 2020, at 10:17, Jean-Michaël Celerier
> >  wrote:
> > 
> > To simplify this step, is there / could there be maybe a
> > -DQT_BUILD_TOOLS_ONLY that would just generate... well, moc, uic, rcc and
> > a couple other friends required for a cross-build ?
> I think that should technically be possible, but I have doubts about it.
> 
> Not all tools are "bootstrap" tools anymore, which means for uic you need to
> build QtCore (same for qmake actually).

The whole point of not bootstrapping the tools for cross compilation is to 
remove as much as we can of the bootstrapping. Right now in 5.15, the only 
tools that really need bootstrapping are qmake and moc. And for 6.0 once the 
build system switch is merged, we can proceed to un-bootstrap qmake too and 
that removes one full level of bootstrapping.

That will leave us with only moc needing bootstrapping. We can therefore 
remove libQt5Bootstrap.a and minimise the amount of work needed to keep the 
bootstrap working.

-- 
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] Switch the main "Qt Build System"

[Thiago Macieira]

On Tuesday, 9 June 2020 05:52:30 PDT Alexandru Croitor wrote:
> > I'm using qmake for Qt6 when I'm doing Android work, also for this reason.
> > I don't want to build Qt twice just to use a "cool and superior" build
> > system.
> Unfortunately that workflow will not work anymore.

Strictly speaking, you don't have to build Qt twice. You can use your system's 
packaged Qt, or Conan or Homebrew or one of the binary builds from qt.io as 
the other. If you don't intend to develop it, you can use the regular, release 
builds made by others.

-- 
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] Switch the main "Qt Build System"

[Thiago Macieira]

On Tuesday, 9 June 2020 00:27:35 PDT Shawn Rutledge wrote:
> FWIW the configuration mechanism seems a bit less friendly so far with all
> those -DSHOUTED options like -DFEATURE_developer_build=ON instead of
> configure -developer-build.

The syntax of CMake was why KDE decided in 2004 not to use CMake and instead 
use Scons/Waf.

Worked out pretty well, right?

The maturity of the project matters  A LOT more than the syntax. Adding a 
wrapper configure script is easy but was never done.

PS: between the initial assessment and when KDE begun using CMake, CMake 
stopped requiring all-uppercase and stopped requiring repeating the conditions 
in the ENDIF() control words.

-- 
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] Switch the main "Qt Build System"

[Elvis Stansvik]

Den tis 9 juni 2020 kl 16:30 skrev Matthew Woehlke :
>
> On 09/06/2020 03.55, Joerg Bornemann wrote:
> > The description of QT_NO_MAKE_TESTS is: "Should tests be built as part
> > of the default 'all' target." Meaning this variable controls whether
> > tests are build by default.
>
> Might I suggest a less obtuse name? Something along the lines of
> QT_TESTS_EXCLUDE_FROM_ALL would be more typical.

+1

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

[Development] Please review 302251

[Matthew Woehlke]

Can I get someone to review 
https://codereview.qt-project.org/c/qt/qtbase/+/302251, please? This 
fixes https://bugreports.qt.io/browse/QTBUG-80577, which has been an 
intermittent problem for my users since last year.


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

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

[Matthew Woehlke]

On 09/06/2020 05.05, Alexandru Croitor wrote:
On 09/06/2020 04.38, Shawn Rutledge wrote: >> At least json is easier to parse, if we try to write other tooling.> 

> That's true. But using tooling to forever generate cmake files from

json also comes with its downsides (maintenance, inability to express
certain constructs, people forgetting to use it, etc).

Personally I think having one source of truth is better. And I think 
tooling for parsing cmake files will appear in time as well.


Alternatively: teach CMake to parse the .json directly.

I think it would make sense for CMake to have some abilities to consume 
and manipulate JSON from CMake script¹, maybe even to use JSON as a 
replacement for the current CMakeCache.txt. (I would *definitely* like 
to see a JSON replacement for how CMake exports targets.) I think you 
might find upstream surprisingly amenable *if* someone is willing to do 
the work.


(¹ ...or from something that *replaces* CMake script. Folks have been 
talking about that for ages, but it comes down to a) agreeing what to 
use, and b) SHTDI. If someone had a *viable* proposal for replacing² 
CMake script, I think you'd find the developers ***very*** interested.)


(² Technically, I should say "supplementing", since CMake script needs 
to stick around for backwards compatibility.)


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

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

[Alexandru Croitor]

On 9. Jun 2020, at 16:30, Matthew Woehlke  wrote:
> 
> On 09/06/2020 03.55, Joerg Bornemann wrote:
>> The description of QT_NO_MAKE_TESTS is: "Should tests be built as part of 
>> the default 'all' target." Meaning this variable controls whether tests are 
>> build by default.
> 
> Might I suggest a less obtuse name? Something along the lines of 
> QT_TESTS_EXCLUDE_FROM_ALL would be more typical.

If you could please file a bug report, or we might forget about it. Or even 
more appreciated - provide a patch.

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

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

[Matthew Woehlke]

On 09/06/2020 03.27, Shawn Rutledge wrote:

FWIW the configuration mechanism seems a bit less friendly so far
with all those -DSHOUTED options like -DFEATURE_developer_build=ON
instead of configure -developer-build.  But there is cmake-gui, which
generates checkboxes for all the options after you have run cmake the
first time.


There's also ccmake, which I usually use on not-Windows. It doesn't 
*filter* the way cmake-gui does, but it does still have searching.


I rarely specify -Dstuff "by hand".


If you have done a build without tests or examples at first (for
speed), and then you want to build some specific ones, how do you do
that?


Enable testing, build specific targets.


I see the same nice configure summary is still generated, but it
would be nice to keep writing that to a file like the old configure
system does, for later inspection.


I haven't looked, but it seems like that should be feasible. Certainly 
you can write files at configure time, so it should be possible to have 
whatever prints this summary wrapped in a helper that both prints to the 
console and also to a file.



Will we keep using the configure.json files and generating
configure.cmake from them?  Then maybe we could write a better gui
later on, that can show checkboxes before you run cmake the first
time.


The problem with this is that options spring into existence *from 
running CMake*. When you have options that depend on other options, you 
can get into a sort of catch-22. This can be somewhat mitigated by 
arranging the CMake logic so that options are declared as soon as 
possible. (It might be useful if there was a non-fatal way to abort 
running CMake when a front-end is in use. You'd still have to 
"configure" once, but that initial configure could be much, much faster 
if all it does is declare options and bail. OTOH, while stuff like 
compiler detection might still need to happen in that first pass, that 
gets cached; you aren't actually doing it twice.)


That's not to say there might not be room for improvement, but lets 
please make any such improvements to CMake itself so that all projects 
using CMake can benefit, not just Qt.


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

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

[Alexandru Croitor]

> On 9. Jun 2020, at 16:09, Alex Blasche  wrote:
> 
> 
> Again this question was referring to the "build Qt module" with CMake Qt (aka 
> your Webengine experiment). Not updating the dependencies is not desired at 
> all. 

Sorry, I missed that the question was about qmake mixing.

You compile qtbase, qtdeclarative, etc with cmake as usual 
(qtbase/cmake/README.md), and then you call qt_prefix_install_path/bin/qmake on 
qtwebengine.pro && make && make install.

I've mentioned though, there are a few known issues tracked at 
https://bugreports.qt.io/browse/QTBUG-84781

> 
> 
>>> About 30 out of 50 modules where set to ignore in gitmodules. About half of
>> those 30 modules get very regular updates at the very least to push their
>> dependencies.yaml forward. Often those cases involve porting to new qtbase
>> changes.
>> 
>> Just as a clarification, the ignored modules in .gitmodules are ignored 
>> initially
>> not due to CMake, but to ease qt5.git integrations because of the fast 
>> turnover
>> in qtbase and qtdeclarative. It would be unfair to pin that on the CMake 
>> port.
> 
> I am not blaming CMake port for the ignored status. I am pointing out a 
> failure of your proposal only doing the non-ignored modules. A lot of ignored 
> modules have a high update frequency which you leave in the lurch with your 
> proposal. Right now this feels to me like releasing Joerg from his qmake duty 
> and bully 60% of all modules into the corner. What you have enabled for CMake 
> in CI will not deteriorate further. You had a trajectory going to convert the 
> non-ignored modules converted. Why stop here and not continue? By 1.8. 
> enabling cmake in CI could be done for 90% of the high turn over modules by 
> the cmake experts, the module experts could continue on the task of updating 
> against the myriads of other API changes. I bet with you that benefit 
> outweighs the qmake maintenance effort.

The trajectory was always to port and enable in the CI, the modules that are 
not ignored in qt5.git.
There was no plan to port all modules in the qt/ namespace by the CMake Port 
team.

Is asking module owners to port to CMake really bullying? 

The fact that CMake configs do not deteriorate in the CI is not true.

While .pro files and qmake are the source of truth, people change the .pro / 
.pri / .prf file. They either forget or don't modify the cmake equivalents. 
Best-case the integration fails and they also do the cmake bits. 
Worst case the change integrates, and somewhere along the way another 
integration fails due to some combination of reasons that includes the fact 
that the previous change did not have the cmake bits.

The usual workflow is then to ask me or Joerg for help because that blocks all 
further integrations.

> 
> Using arguments like the python scripts pro2cmake.py is not effort. It 
> doesn't count as argument

Not sure i understand this point.

>> 
>> I guess my best answer is: over time, yes.
>> 
>> I'm slowly doing that for iOS and qemu, but it's a very slow process because 
>> i
>> need to wait for qtbase integrations (where my fixes usually are) to 
>> propagate
>> to other repos, or all the way to qt5.
>> 
>>> This creates a big long term problem. For example:
>>> 
>>> - there is only on mac build one cmake -> 3 qmake (drops
>>> debug-and-release, drops building examples, no developer build)
>> 
>> We didn't want to blow up Coin integration times, so we didn't include so far
>> every possible configuration.
>> Building examples and developer build activation is a simple change. For 
>> debug-
>> and-release we are waiting for the CMake 3.18 official release.
> 
> Take one qmake config off and add an equivalent cmake conf. You swap one for 
> one. There is no blow up. This is something you can do even today and you 
> don't need to change any policy.

If we gradually replace qmake configs with cmake configs, then we lose qmake 
coverage, which means that people using qmake to build the modules will more 
likely start getting failures (especially in leaf modules), and this will again 
split the effort of fixing issues in 2 build systems.

> 
>>> - Linux QEMU  (completely dropped from auto testing)
>> 
>> That's on the to do list to enable.
>> 
>>> - WebAssembly completely lost
>> 
>> That is true. As I mentioned in my reply to Andre, we tested it at some 
>> point, but
>> we don't have current plans to add it to the CI.
>> 
>>> - not a single namespace or libinfix build left (afaict)
>> 
>> That's also true, and would have to be investigated.
>> 
>>> - various other configurations are missing too
>>> 
>>> Unless we can at least convert a couple more CI configurations to cmake it
>> sounds to me we want to save effort on the build system side against a big 
>> black
>> box of unknown/not tested problems we won't even notice.
>> 
>> That is also true. But I'll ask one more time. How long do we wait? When
>> everything is perfectly ready? What if that takes too long and doesn't fit 
>> in 

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

[Matthew Woehlke]

On 09/06/2020 03.55, Joerg Bornemann wrote:
The description of QT_NO_MAKE_TESTS is: "Should tests be built as part 
of the default 'all' target." Meaning this variable controls whether 
tests are build by default.


Might I suggest a less obtuse name? Something along the lines of 
QT_TESTS_EXCLUDE_FROM_ALL would be more typical.


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

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

[Alex Blasche]

> -Original Message-
> From: Alexandru Croitor 

> > Could you share details how this is done?
> 
> Which part?
> First we'd have to remove all qmake configs in qt5.git/coin/platform_configs,
> leaving just the cmake ones.
> Once that's integrated, we can push & stage changes that remove .pro files.

This was referring directly to the line above it. How do I build a qmake module 
using CMake Qt? You mentioned the possibility and having done so with webengine 
but never provided details.
 
> > Can I assume that existing CI targets for those not activated cmake modules
> continue to work (despite continuing dependencies.yaml updates)?
> 
> If a module does not have a cmake port, the safe option is to use dependency
> sha1s that still have the .pro files, which means you can't update
> dependencies.yaml past that point.

Again this question was referring to the "build Qt module" with CMake Qt (aka 
your Webengine experiment). Not updating the dependencies is not desired at 
all. 


> > About 30 out of 50 modules where set to ignore in gitmodules. About half of
> those 30 modules get very regular updates at the very least to push their
> dependencies.yaml forward. Often those cases involve porting to new qtbase
> changes.
> 
> Just as a clarification, the ignored modules in .gitmodules are ignored 
> initially
> not due to CMake, but to ease qt5.git integrations because of the fast 
> turnover
> in qtbase and qtdeclarative. It would be unfair to pin that on the CMake port.

I am not blaming CMake port for the ignored status. I am pointing out a failure 
of your proposal only doing the non-ignored modules. A lot of ignored modules 
have a high update frequency which you leave in the lurch with your proposal. 
Right now this feels to me like releasing Joerg from his qmake duty and bully 
60% of all modules into the corner. What you have enabled for CMake in CI will 
not deteriorate further. You had a trajectory going to convert the non-ignored 
modules converted. Why stop here and not continue? By 1.8. enabling cmake in CI 
could be done for 90% of the high turn over modules by the cmake experts, the 
module experts could continue on the task of updating against the myriads of 
other API changes. I bet with you that benefit outweighs the qmake maintenance 
effort.

Using arguments like the python scripts pro2cmake.py is not effort. It doesn't 
count as argument


> Also note that merging the wip/cmake branches to dev is fine from my point of
> view. The problem is enabling it in the blocking CI, because if the port 
> doesn't
> work, you're blocking any further integrations. There's also the minor issue 
> that
> people might see the cmakelists.txt and think that means the port is done, but
> that's minor in the grand scheme of things.
>
> See my previous replies regarding qmake mixing (qmake against CMake Qt).

Please provide the details. How does one set such a build up?

> >> --> Proposed time of execution: 1st of July <--
> >>
> >>
> >> I'd like to hear about any Qt development blockers that you foresee
> >> due to this change.
> >
> > Will you create test/configuration parity in the CI? Currently the CMake
> configurations don't even cover all the config options we support via qmake.
> 
> I guess my best answer is: over time, yes.
> 
> I'm slowly doing that for iOS and qemu, but it's a very slow process because i
> need to wait for qtbase integrations (where my fixes usually are) to propagate
> to other repos, or all the way to qt5.
> 
> > This creates a big long term problem. For example:
> >
> > - there is only on mac build one cmake -> 3 qmake (drops
> > debug-and-release, drops building examples, no developer build)
> 
> We didn't want to blow up Coin integration times, so we didn't include so far
> every possible configuration.
> Building examples and developer build activation is a simple change. For 
> debug-
> and-release we are waiting for the CMake 3.18 official release.

Take one qmake config off and add an equivalent cmake conf. You swap one for 
one. There is no blow up. This is something you can do even today and you don't 
need to change any policy.

> > - Linux QEMU  (completely dropped from auto testing)
> 
> That's on the to do list to enable.
> 
> > - WebAssembly completely lost
> 
> That is true. As I mentioned in my reply to Andre, we tested it at some 
> point, but
> we don't have current plans to add it to the CI.
> 
> > - not a single namespace or libinfix build left (afaict)
> 
> That's also true, and would have to be investigated.
> 
> > - various other configurations are missing too
> >
> > Unless we can at least convert a couple more CI configurations to cmake it
> sounds to me we want to save effort on the build system side against a big 
> black
> box of unknown/not tested problems we won't even notice.
> 
> That is also true. But I'll ask one more time. How long do we wait? When
> everything is perfectly ready? What if that takes too long and doesn't fit in 
> the
> 

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

[Alexandru Croitor]

> On 9. Jun 2020, at 13:56, Alex Blasche  wrote:
> 
> 
> Could you share details how this is done?

Which part?
First we'd have to remove all qmake configs in qt5.git/coin/platform_configs, 
leaving just the cmake ones.
Once that's integrated, we can push & stage changes that remove .pro files.


> Can I assume that existing CI targets for those not activated cmake modules 
> continue to work (despite continuing dependencies.yaml updates)?

If a module does not have a cmake port, the safe option is to use dependency 
sha1s that still have the .pro files, which means you can't update 
dependencies.yaml past that point. 

You can try updating dependencies.yaml past the removal point and thus try 
using the qmake mixing, but as I've mentioned in a previous reply
I can't guarantee that it will work for all modules in all configurations.

The best way is to port the module to CMake.

> 
> About 30 out of 50 modules where set to ignore in gitmodules. About half of 
> those 30 modules get very regular updates at the very least to push their 
> dependencies.yaml forward. Often those cases involve porting to new qtbase 
> changes. 

Just as a clarification, the ignored modules in .gitmodules are ignored 
initially not due to CMake, but to ease qt5.git integrations because of the 
fast turnover in qtbase and qtdeclarative. It would be unfair to pin that on 
the CMake port.

> A lot of those modules have a cmake port in a side branch. When asked about 
> this a few weeks ago why we shouldn't merge them to dev you stated that you 
> don't have the bandwidth to help people activating them in the CI. Do you 
> suddenly have the bandwidth to help all those module maintainers to port them 
> to cmake or even enable the qmake against CMake Qt? 

I never have enough bandwidth. 

That being said, I still try to help the maintainers with the ports and 
activating them in the CI (see for example qtopcua, qt3d and qtmqtt).

I believe I also provided feedback for one of the modules that you were trying 
to enable in the CI.

Also note that merging the wip/cmake branches to dev is fine from my point of 
view. The problem is enabling it in the blocking CI, because if the port 
doesn't work, you're blocking any further integrations. There's also the minor 
issue that people might see the cmakelists.txt and think that means the port is 
done, but that's minor in the grand scheme of things.

See my previous replies regarding qmake mixing (qmake against CMake Qt).

> 
> 
>> --> Proposed time of execution: 1st of July <--
>> 
>> 
>> I'd like to hear about any Qt development blockers that you foresee due to 
>> this
>> change.
> 
> Will you create test/configuration parity in the CI? Currently the CMake 
> configurations don't even cover all the config options we support via qmake.

I guess my best answer is: over time, yes. 

I'm slowly doing that for iOS and qemu, but it's a very slow process because i 
need to wait for qtbase integrations (where my fixes usually are) to propagate 
to other repos, or all the way to qt5.

> This creates a big long term problem. For example:
> 
> - there is only on mac build one cmake -> 3 qmake (drops debug-and-release, 
> drops building examples, no developer build)

We didn't want to blow up Coin integration times, so we didn't include so far 
every possible configuration.
Building examples and developer build activation is a simple change. For 
debug-and-release we are waiting for the CMake 3.18 official release.

> - Linux QEMU  (completely dropped from auto testing)

That's on the to do list to enable.

> - WebAssembly completely lost

That is true. As I mentioned in my reply to Andre, we tested it at some point, 
but we don't have current plans to add it to the CI.

> - not a single namespace or libinfix build left (afaict)

That's also true, and would have to be investigated.

> - various other configurations are missing too
> 
> Unless we can at least convert a couple more CI configurations to cmake it 
> sounds to me we want to save effort on the build system side against a big 
> black box of unknown/not tested problems we won't even notice. 

That is also true. But I'll ask one more time. How long do we wait? When 
everything is perfectly ready? What if that takes too long and doesn't fit in 
the 6.0 release schedule or feature freeze or platform freeze, or any other 
randomly chosen milestone period?


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

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

[Alexandru Croitor]

> On 9. Jun 2020, at 13:25, Bogdan Vatra via Development 
>  wrote:
> 
> But how can I send a fix to a .pr* file in dev if that file doesn't exists 
> anymore in dev? In this case should we send the patches directly to 5.15. and 
> add the "Cherry-pick: dev" thing to the patch message?

I think the idea is that your change initially targets the dev branch, and has 
a Pick-to: 5.15 footer.

Let's say you will touch src/corelib/CMakeLists.txt and qlocale.cpp.

When the cherry-pick bot creates the cherry-pick, it fails to apply the 
CMakeLists.txt file change.
You then amend that change to remove the CMakeLists.txt change, and replace it 
with the .pro change.
You could perhaps prepare the .pro file change beforehand locally, and just 
amend the Change-Id once the cherry-pick bots creates it.


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

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

[Alexandru Croitor]

> On 9. Jun 2020, at 13:20, Shawn Rutledge  wrote:
> 
> 
>> On 2020 Jun 9, at 11:05, Alexandru Croitor  wrote:
>> 
>>> On 9. Jun 2020, at 10:38, Shawn Rutledge  wrote:
>>> 
>>> Well that’s a little extra maintenance work then; I agree that configure is 
>>> nicer, but maybe we can expect the cmake way of configuring to generally be 
>>> more up-to-date if that’s where each change starts.
>> 
>> Up-to-date how? 
> 
> A new flag is defined to exist when it's available to cmake.  But if you say 
> that configure needs work to stay in sync, then maybe that’s delayed?

Sorry but I don't understand what you mean.

> 
>> Are you suggesting modifying upstream cmake to accept things like 
>> --developer-build and map that to -DDEVELOPER_BUILD=ON or something along 
>> those lines?
> 
> Do you mean cmake could generally try convert unidentified --xxx to -DXXX=ON, 
> or just a few flags that Qt and other projects might agree to use?  I guess 
> either way it depends whether such upstream features would be useful to other 
> projects.

I was thinking more of the former approach (--xxx to -DXXX=ON), but yes, it 
would need convincing upstream, and i'm not sure how willing they might be to 
do such a change.

> 
>> I think we'll have to investigate if there's any better way to address 
>> discoverability. One random idea would be to provide a --list-features 
>> option to configure which behind the scenes calls a separate cmake script 
>> that finds and includes all configure.cmake files, collates a list of 
>> features and prints them on the command line.
> 
> For cmake to be able to read config files and generate a list of possible 
> flags without doing a lot of other work sounds like a useful upstream feature.

I suppose. But that's just one more "useful" feature in the pile of 
"nice-to-have-features" for CMake. Unfortunately there's always a lack of 
people to implement them.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

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

[Alexandru Croitor]

> On 9. Jun 2020, at 12:07, Bogdan Vatra  wrote:
> 
> Hi,
> În ziua de marți, 9 iunie 2020, la 11:13:21 EEST, Alexandru Croitor a scris:
>>> On 9. Jun 2020, at 07:22, Bogdan Vatra  wrote:
>>> 
>>> - is it possible to cross compile Qt in one go (just like we do with
>>> qmake)?
>> Could you clarify what you mean by "in one go"?
>> 
>> If it's about building host tools as part of the cross-compilation, then no.
>> You first have to build a desktop Qt, and re-use that host Qt installation
>> for its tools, to cross-compile to another target.
>> 
>> That's been one of the goals for Qt 6 regardless of build system, and has
>> been communicated a while ago.
> 
> When I'm cross-compiling Qt for a Linux device, Android, ios, etc., qmake 
> it's 
> smart enough to build everything for me: host tools and the libs for that 
> target in one go i.e. I type ./configure .. && make and it does all the magic 
> for me.
> 
> How qt modules that have host & target libs will be built with cmake?

Like I mentioned in my previous reply, you will have to call configure && make 
twice, once for the host build and once for target build.
And I will reiterate, this has nothing to do with CMake. 
A decision was made to decouple host builds from target builds, regardless of 
the build tool used.

That magic that you rely on works in 90% cases, and breaks in weird ways for 
other users, as well as creating a maintenance burden for package maintainers 
(linux distros, Qt itself, vcpkg, conan, etc)

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

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

I think those were pointed out and discussed in previous mailing list 
discussions.

Personally i don't want to spend time to try convincing anyone in either 
direction.

There are advantages and disadvantages, as to any solution.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

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

[Alexandru Croitor]

> On 9. Jun 2020, at 11:36, Edward Welbourne  wrote:
> 
> Alexandru Croitor (9 June 2020 10:41)
>> I'll acknowledge that the current Qt Creator <-> Build Qt with CMake 
>> situation is sub-par.
> 
> Is there a P1 ticket open about that ?
> Might even warrant P0, given ...

I created a bug report here

And wrote a public wiki page on how to use Creator to open the Qt CMake 
projects. It contains the method i tried that worked for me (method 2)
and Eike's (method 1).

https://bugreports.qt.io/browse/QTCREATORBUG-24159

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

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

[Marius Kittler]

Hi,

Am Dienstag, 9. Juni 2020, 12:07:02 CEST schrieb Bogdan Vatra via Development:
> I'm using qmake for Qt6 when I'm doing Android work, also for this reason.
> I don't want to build Qt twice just to use a "cool and superior" build system.
>
> Just out of curiosity, can some pretty please remind me what are the
> advantages of using cmake to build Qt over qmake?
> I'm not talking about Qt users, for them we should support all (major) build
> systems: qmake, cmake, meson, etc.

It seems we have quite different use-cases and workflows because I actually 
understood that as a useful change - especially the part that Qt no longer 
weirdly builds for two target (host and actual target) in one go, see my 
comment here:
https://aur.archlinux.org/packages/mingw-w64-qt5-base/#pinned-750114

Additionally:

When building only for one target at a time it is always clear to which target 
compiler flags, linker flags, dependency lookups and so on apply. That removes 
a lot of complexity from the build system.

So far I'm building qmake, bootstrapping libraries and other tools for i686-
w64-mingw32, x86_64-w64-mingw32, x86_64-linux-android, arm-linux-androideabi 
and aarch64-linux-android and in the future maybe for even more targets. In Qt 
6 I will be able to save built time on all of these targets by simply making 
use of the host version of Qt. That sounds like a clear win since the host 
version of Qt should be available on all platforms I possibly want to build 
for these targets.

The multi-ABI build for Android looks more like a hack to workaround having to 
build host tools multiple times. It comes with the disadvantage of making the 
build process more complex. Features which work for other targets like using 
system provided libraries instead of the bundled ones are likely problematic 
due to that. At the same time it is limited to Android and not a generic 
feature. If the goal is to make one Android package which contains binaries 
built for different targets: Why not simply let androiddeployqt pick up these 
binaries from different builds? Just allow one to pass multiple install 
directories/prefixes for these libraries at a time. That sounds way simpler 
and would also work for other dependencies a project might have besides Qt.

Best Regards
Marius


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

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

[Alex Blasche]

> -Original Message-
> From: Development  On Behalf Of
> Alexandru Croitor
 
> -> TL;DR here 
> <
> 
> The CMake Port team wants to switch the main Qt build system to the CMake
> one.
> 
> What this means:
> 
> - All Coin qmake configurations in dev branch are removed.
> 
> - Only CMake configurations are built in Coin.
> 
> - CMakeLists.txt files are now the source of truth (no more editing of .pro / 
> .pri
> files).
> 
> - All qmake .pro / .pri files of ported repositories under Coin control are
> removed.
> 
> - No more pro2cmake.py and configurejson2cmake.py usage (except for an
> initial port of a yet un-ported repository)
> 
> - You need CMake to build Qt.
> 
> - Un-ported repositories should still be able to build with qmake against a 
> CMake
> built Qt (this was tested to work for qtwebengine, but not other repositories,
> there are a few known issues left that we're currently fixing).

Could you share details how this is done? Can I assume that existing CI targets 
for those not activated cmake modules continue to work (despite continuing 
dependencies.yaml updates)?

About 30 out of 50 modules where set to ignore in gitmodules. About half of 
those 30 modules get very regular updates at the very least to push their 
dependencies.yaml forward. Often those cases involve porting to new qtbase 
changes. 
A lot of those modules have a cmake port in a side branch. When asked about 
this a few weeks ago why we shouldn't merge them to dev you stated that you 
don't have the bandwidth to help people activating them in the CI. Do you 
suddenly have the bandwidth to help all those module maintainers to port them 
to cmake or even enable the qmake against CMake Qt? 

 
> --> Proposed time of execution: 1st of July <--
> 
> 
> I'd like to hear about any Qt development blockers that you foresee due to 
> this
> change.

Will you create test/configuration parity in the CI? Currently the CMake 
configurations don't even cover all the config options we support via qmake. 
This creates a big long term problem. For example:

- there is only on mac build one cmake -> 3 qmake (drops debug-and-release, 
drops building examples, no developer build)
- Linux QEMU  (completely dropped from auto testing)
- WebAssembly completely lost
- not a single namespace or libinfix build left (afaict)
- various other configurations are missing too

Unless we can at least convert a couple more CI configurations to cmake it 
sounds to me we want to save effort on the build system side against a big 
black box of unknown/not tested problems we won't even notice. 

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

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

[Bogdan Vatra via Development]

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

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

Cheers,
BogDan.

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

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

[Shawn Rutledge]

> On 2020 Jun 9, at 11:05, Alexandru Croitor  wrote:
> 
>> On 9. Jun 2020, at 10:38, Shawn Rutledge  wrote:
>> 
>> Well that’s a little extra maintenance work then; I agree that configure is 
>> nicer, but maybe we can expect the cmake way of configuring to generally be 
>> more up-to-date if that’s where each change starts.
> 
> Up-to-date how? 

A new flag is defined to exist when it's available to cmake.  But if you say 
that configure needs work to stay in sync, then maybe that’s delayed?

> Are you suggesting modifying upstream cmake to accept things like 
> --developer-build and map that to -DDEVELOPER_BUILD=ON or something along 
> those lines?

Do you mean cmake could generally try convert unidentified --xxx to -DXXX=ON, 
or just a few flags that Qt and other projects might agree to use?  I guess 
either way it depends whether such upstream features would be useful to other 
projects.

> I think we'll have to investigate if there's any better way to address 
> discoverability. One random idea would be to provide a --list-features option 
> to configure which behind the scenes calls a separate cmake script that finds 
> and includes all configure.cmake files, collates a list of features and 
> prints them on the command line.

For cmake to be able to read config files and generate a list of possible flags 
without doing a lot of other work sounds like a useful upstream feature.

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

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

[Edward Welbourne]

On 6/9/20 7:22 AM, Bogdan Vatra via Development wrote:
>>> - if you'll not support/trash all .pro/.pri files how we'll push
>>> fixes for 5.15 branch ? Because right now we can't push fixes
>>> directly to 5.15.  branch and all the fixes must go trough dev
>>> branch first.

În ziua de marți, 9 iunie 2020, la 10:35:33 EEST, Joerg Bornemann a scris:
>> All changes that do not apply to Qt6 must go to 5.15.  It's not true
>> that we can't push fixes to 5.15 anymore.

Bogdan Vatra (9 June 2020 12:12)
> If I have a fix which involves also changes to some .pr* files, where
> it should go? In dev I can't push it because you nuked the .pr* files,
> in 5.15 I'm banned.

This is by no means unique to .pr[fio] files: there's lots of code that
we've deleted on dev, that shall need fixes on 5.15.  When a fix gets
picked to 5.15, there is a risk that it'll apply and maybe even
integrate; if so, a follow-up commit only on 5.15 can supply the parts
of the change that aren't present on dev.  More usually, the pick will
get conflicts or fail to integrate, so you'll get the chance to amend
the picked commit on 5.15.  (Even in the first case, if you get the mail
promptly, you can potentially unstage the pick before it gets integrated
and fix it likewise.)

This applies to all the code that's being deleted on dev, including but
by no means limited to qmake's configuration.

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

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

[Eike Ziller]

> On Jun 9, 2020, at 12:07, Eike Ziller  wrote:
> 
> 
> 
>> On Jun 9, 2020, at 09:59, Andy Nichols  wrote:
>> 
>> Hi Alexandru,
>> 
>> I think Brett touches on the biggest blocker for me and that is actually 
>> related to Qt Creators ability to open and use modules built using cmake.  I 
>> am actually really impressed with state of the CMake support for build Qt as 
>> it is right now, and wish I could more actively use it, but unfortunately my 
>> current workflow involves using Qt Creator to develop Qt, and I have to work 
>> on modules that are not just QtBase.  Despite adding my cmake based Qt 
>> Builds to Creator as kits (which seems to only be possible using qmake), it 
>> isn't possible for Creator to easily recognize that my module's are built 
>> with that kit when loading them.  I hear rumors that it is possible, but 
>> most of the guys who say that are only working on qtbase anyway.
>> 
>> I think that before we kill the qmake based build of Qt, that our own IDE 
>> should support developing Qt itself.  And I would be happy with some 
>> "sketchy config" that works with a released version of Qt Creator for now, 
>> but this shouldn't be good enough to justify killing qmake before a real 
>> solution is in place.
> 
> Hi, I just tried opening qtdeclarative in Qt Creator 4.12.2 (on macOS).
> 
> 1) build (and install) qtbase with cmake on command line
> 2) build (and install) qtdeclarative with cmake on command line (with 
> qt-cmake  && cmake —build .)
> 3) register the Qt version in Qt Creator (Pointing it to the qmake that was 
> built in (1)), press Apply
> 4) create a kit with that Qt version in Qt Creator
> 5) make sure compiler is set sensibly

5b) make sure the CMake Generator is set correctly

> 6) remove everything from the “CMake Configuration” from the kit
> 7) open the qtdeclarative/CMakeLists.txt in Qt Creator, check the kit that 
> you created and change the build directory to qtdeclarative’s build directory
> 
> On a short glance that seemed to work. No code model warnings, triggering a 
> build triggers a build.
> 
> Step 6 is to try to minimize the fiddling that Qt Creator does with the build 
> directory.
> Whenever Qt Creator says that the “Qt Creator project” and the “cmake build 
> directory” disagree, choose to “Adapt Qt Creator Project” to the cmake build 
> directory.
> This will hopefully work better in Qt Creator 4.13 where we make Qt Creator 
> to accept an existing CMake build directory as “the one truth to rule it all”.
> 
> “Importing" the qt/module build into Qt Creator, i.e. automatically creating 
> a kit from the build indeed doesn’t seem to work. The compiler is empty in 
> the generated Kit for me, and Qt Creator 4.12 then explicitly passes 
> CMAKE_CXX_COMPILER=“”. Even though the original CMakeCache.txt contains the 
> correct entry, and that compiler is actually already registered in Qt Creator.
> The Qt version in the kit is empty too. Detecting that seems to be a bit more 
> difficult, but since CMake gives us the relevant include paths anyhow that 
> might not be such an issue.
> 
> -- 
> Eike Ziller
> Principal Software Engineer
> 
> The Qt Company GmbH
> Erich-Thilo-Straße 10
> D-12489 Berlin
> eike.zil...@qt.io
> http://qt.io
> Geschäftsführer: Mika Pälsi,
> Juha Varelius, Mika Harjuaho
> Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, 
> HRB 144331 B

-- 
Eike Ziller
Principal Software Engineer

The Qt Company GmbH
Erich-Thilo-Straße 10
D-12489 Berlin
eike.zil...@qt.io
http://qt.io
Geschäftsführer: Mika Pälsi,
Juha Varelius, 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] Switch the main "Qt Build System"

[Bogdan Vatra via Development]

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

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

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

Cheers,
BogDan.

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

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

[Eike Ziller]

> On Jun 9, 2020, at 09:59, Andy Nichols  wrote:
> 
> Hi Alexandru,
> 
> I think Brett touches on the biggest blocker for me and that is actually 
> related to Qt Creators ability to open and use modules built using cmake.  I 
> am actually really impressed with state of the CMake support for build Qt as 
> it is right now, and wish I could more actively use it, but unfortunately my 
> current workflow involves using Qt Creator to develop Qt, and I have to work 
> on modules that are not just QtBase.  Despite adding my cmake based Qt Builds 
> to Creator as kits (which seems to only be possible using qmake), it isn't 
> possible for Creator to easily recognize that my module's are built with that 
> kit when loading them.  I hear rumors that it is possible, but most of the 
> guys who say that are only working on qtbase anyway.
> 
> I think that before we kill the qmake based build of Qt, that our own IDE 
> should support developing Qt itself.  And I would be happy with some "sketchy 
> config" that works with a released version of Qt Creator for now, but this 
> shouldn't be good enough to justify killing qmake before a real solution is 
> in place.

Hi, I just tried opening qtdeclarative in Qt Creator 4.12.2 (on macOS).

1) build (and install) qtbase with cmake on command line
2) build (and install) qtdeclarative with cmake on command line (with qt-cmake 
 && cmake —build .)
3) register the Qt version in Qt Creator (Pointing it to the qmake that was 
built in (1)), press Apply
4) create a kit with that Qt version in Qt Creator
5) make sure compiler is set sensibly
6) remove everything from the “CMake Configuration” from the kit
7) open the qtdeclarative/CMakeLists.txt in Qt Creator, check the kit that you 
created and change the build directory to qtdeclarative’s build directory

On a short glance that seemed to work. No code model warnings, triggering a 
build triggers a build.

Step 6 is to try to minimize the fiddling that Qt Creator does with the build 
directory.
Whenever Qt Creator says that the “Qt Creator project” and the “cmake build 
directory” disagree, choose to “Adapt Qt Creator Project” to the cmake build 
directory.
This will hopefully work better in Qt Creator 4.13 where we make Qt Creator to 
accept an existing CMake build directory as “the one truth to rule it all”.

“Importing" the qt/module build into Qt Creator, i.e. automatically creating a 
kit from the build indeed doesn’t seem to work. The compiler is empty in the 
generated Kit for me, and Qt Creator 4.12 then explicitly passes 
CMAKE_CXX_COMPILER=“”. Even though the original CMakeCache.txt contains the 
correct entry, and that compiler is actually already registered in Qt Creator.
The Qt version in the kit is empty too. Detecting that seems to be a bit more 
difficult, but since CMake gives us the relevant include paths anyhow that 
might not be such an issue.

-- 
Eike Ziller
Principal Software Engineer

The Qt Company GmbH
Erich-Thilo-Straße 10
D-12489 Berlin
eike.zil...@qt.io
http://qt.io
Geschäftsführer: Mika Pälsi,
Juha Varelius, 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] Switch the main "Qt Build System"

[Bogdan Vatra via Development]

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

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

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

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

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

Cheers,
BogDan.


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

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

[Tuukka Turunen]

Hi,

"Putting that aside, how long should we wait then? " is exactly the question we 
would like to find the answer to __

My own preference is to make the switch to CMake as soon as possible and use 
effort to improving the CMake port instead of keeping the qmake as a parallel 
build system for Qt itself. Having the mixing support as an option is 
beneficial, and something we wanted to offer to the extent feasible without 
risking the overall Qt 6.0 development. 

We are currently at a point where all the most commonly used modules are built 
with CMake. There is a bit less than 3 months to Qt 6.0 feature freeze and 
around 8 months to Qt 6.1 feature freeze. This should be adequate time to make 
the changes in all the relevant modules. 

The goal is for all the Qt 6.0 modules are in place at the Structure and 
platform freeze milestone (end of June, https://wiki.qt.io/Qt_6.0_Release). 
This allows us to have things ready well before the feature freeze - and avoid 
situations where some larger changes are done close to the FF deadline, 
potentially causing instability. We should not accept any modules that are 
still built with qmake to the Qt 6.0 release content. 

So, let's continue the discussion and aim to reach the conclusion in the next 
few days for the best path forward related to the topic. 

Yours,

Tuukka

 

On 9.6.2020, 11.45, "Development on behalf of Alexandru Croitor" 
 wrote:

Hi Andy,

I'll acknowledge that the current Qt Creator <-> Build Qt with CMake 
situation is sub-par.

Though, I believe there is a sketchy config to allow you to use a released 
Qt Creator to develop Qt.


Putting that aside, how long should we wait then? 

I'm not sure if we can afford to delay the switch for much longer, for many 
reasons:

- I don't know how long it would take to improve Creator to do "the right 
thing".
- The Qt releasing team needs to start creating and testing packages based 
on the CMake-built Qt
- Developers are burdened with maintaining 2 build systems (not just the 
CMake port team, but also other developers doing regular Qt6.0 work)

We have to bite the bullet at some point.

> On 9. Jun 2020, at 09:59, Andy Nichols  wrote:
> 
> Hi Alexandru,
> 
> I think Brett touches on the biggest blocker for me and that is actually 
related to Qt Creators ability to open and use modules built using cmake.  I am 
actually really impressed with state of the CMake support for build Qt as it is 
right now, and wish I could more actively use it, but unfortunately my current 
workflow involves using Qt Creator to develop Qt, and I have to work on modules 
that are not just QtBase.  Despite adding my cmake based Qt Builds to Creator 
as kits (which seems to only be possible using qmake), it isn't possible for 
Creator to easily recognize that my module's are built with that kit when 
loading them.  I hear rumors that it is possible, but most of the guys who say 
that are only working on qtbase anyway.
> 
> I think that before we kill the qmake based build of Qt, that our own IDE 
should support developing Qt itself.  And I would be happy with some "sketchy 
config" that works with a released version of Qt Creator for now, but this 
shouldn't be good enough to justify killing qmake before a real solution is in 
place.

___
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] Switch the main "Qt Build System"

[Edward Welbourne]

Alexandru Croitor (9 June 2020 10:41)
> I'll acknowledge that the current Qt Creator <-> Build Qt with CMake 
> situation is sub-par.

Is there a P1 ticket open about that ?
Might even warrant P0, given ...

> We have to bite the bullet at some point.

In particular, the "Structure and platform freeze" at the end of June is
only three weeks away.  I'm guessing we need Coin migrated to CMake by
then.  We need CMake to be the usual mode of development by then.
Notably including: for those using Qt Creator ...

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

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

[Alexandru Croitor]

> On 9. Jun 2020, at 10:38, Shawn Rutledge  wrote:
> 
> Well that’s a little extra maintenance work then; I agree that configure is 
> nicer, but maybe we can expect the cmake way of configuring to generally be 
> more up-to-date if that’s where each change starts.

Up-to-date how? 
Are you suggesting modifying upstream cmake to accept things like 
--developer-build and map that to -DDEVELOPER_BUILD=ON or something along those 
lines?

> 
>> Indeed currently you need to run CMake at least once to get all the 
>> checkboxes. I have an idea of how we might improve that (so you don't have 
>> to run it once) but it's not done yet.
> 
> Do you want to explain?

It appears I was mistaken. I was under the impression that the CMake Gui can 
show some options before doing "configure" at least once, but it doesn't seem 
to be the case.

Some details about that here 
https://gitlab.kitware.com/cmake/cmake/-/issues/17083

I think we'll have to investigate if there's any better way to address 
discoverability. One random idea would be to provide a --list-features option 
to configure which behind the scenes calls a separate cmake script that finds 
and includes all configure.cmake files, collates a list of features and prints 
them on the command line.

> 
>>> Will we keep using the configure.json files and generating configure.cmake 
>>> from them? 
>> 
>> It's possible, but it might make sense to to use configure.cmake as the 
>> source of truth as well. I don't believe we discussed that internally yet.
> 
> At least json is easier to parse, if we try to write other tooling.

That's true. But using tooling to forever generate cmake files from json also 
comes with its downsides (maintenance, inability to express certain constructs, 
people forgetting to use it, etc). 

For the last one you could introduce more tooling like a sanity bot check that 
a cmake file always needs to be generated if a .json file got touched, but that 
might have false positives, etc.

Personally I think having one source of truth is better. And I think tooling 
for parsing cmake files will appear in time as well.

> 
> ___
> 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] Switch the main "Qt Build System"

[Alexandru Croitor]

Hi Andy,

I'll acknowledge that the current Qt Creator <-> Build Qt with CMake situation 
is sub-par.

Though, I believe there is a sketchy config to allow you to use a released Qt 
Creator to develop Qt.


Putting that aside, how long should we wait then? 

I'm not sure if we can afford to delay the switch for much longer, for many 
reasons:

- I don't know how long it would take to improve Creator to do "the right 
thing".
- The Qt releasing team needs to start creating and testing packages based on 
the CMake-built Qt
- Developers are burdened with maintaining 2 build systems (not just the CMake 
port team, but also other developers doing regular Qt6.0 work)

We have to bite the bullet at some point.

> On 9. Jun 2020, at 09:59, Andy Nichols  wrote:
> 
> Hi Alexandru,
> 
> I think Brett touches on the biggest blocker for me and that is actually 
> related to Qt Creators ability to open and use modules built using cmake.  I 
> am actually really impressed with state of the CMake support for build Qt as 
> it is right now, and wish I could more actively use it, but unfortunately my 
> current workflow involves using Qt Creator to develop Qt, and I have to work 
> on modules that are not just QtBase.  Despite adding my cmake based Qt Builds 
> to Creator as kits (which seems to only be possible using qmake), it isn't 
> possible for Creator to easily recognize that my module's are built with that 
> kit when loading them.  I hear rumors that it is possible, but most of the 
> guys who say that are only working on qtbase anyway.
> 
> I think that before we kill the qmake based build of Qt, that our own IDE 
> should support developing Qt itself.  And I would be happy with some "sketchy 
> config" that works with a released version of Qt Creator for now, but this 
> shouldn't be good enough to justify killing qmake before a real solution is 
> in place.

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

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

[Shawn Rutledge]

> On 2020 Jun 9, at 10:21, Alexandru Croitor  wrote:
> 
>> On 9. Jun 2020, at 09:27, Shawn Rutledge  wrote:
>> 
>> FWIW the configuration mechanism seems a bit less friendly so far with all 
>> those -DSHOUTED options like -DFEATURE_developer_build=ON instead of 
>> configure -developer-build.  But there is cmake-gui, which generates 
>> checkboxes for all the options after you have run cmake the first time.  
>> They are even searchable.  Is that a recommended way to discover the 
>> configure options?  (Too bad you have to run cmake twice then.
> 
> Joerg already answered about this.
> 
> At least in my opinion, I think we should keep configure script because it's 
> a nice developer interface. Some mappings are currently missing, but people 
> could help us out there.

Well that’s a little extra maintenance work then; I agree that configure is 
nicer, but maybe we can expect the cmake way of configuring to generally be 
more up-to-date if that’s where each change starts.

> Indeed currently you need to run CMake at least once to get all the 
> checkboxes. I have an idea of how we might improve that (so you don't have to 
> run it once) but it's not done yet.

Do you want to explain?

>> Will we keep using the configure.json files and generating configure.cmake 
>> from them? 
> 
> It's possible, but it might make sense to to use configure.cmake as the 
> source of truth as well. I don't believe we discussed that internally yet.

At least json is easier to parse, if we try to write other tooling.

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

[Development] Using clazy to build Qt and Qt-based projects

[Shawn Rutledge]

Since https://codereview.qt-project.org/c/qt/qtbase/+/303079 
 landed, there are a 
lot of deprecation warnings.  I’ve been using clazy to fix them, as in 
https://codereview.qt-project.org/c/qt/qtbase/+/303079 
 and 
https://codereview.qt-project.org/c/qt/qtsvg/+/303448 
. To make that possible, 
I added a qevent-accessors check to it, which is currently on the tip of my 
fork:  https://github.com/ec1oud/clazy . I 
plan to try to upstream that change.  But there might end up being more things 
that need to be done with QEvent accessors, so maybe it’s a little early to 
finalize what changes this particular qevent-accessors check will suggest.

A clazy check just generates more warnings in general; but it can also include 
replacement text (a source code change).  Most pre-existing checks do not yet 
include fixes, but IMO it’s much more useful if it does include a “fixit”, 
because that can be automatically applied.  You can see in my patch how I did 
that.  Discovering llvm APIs isn’t so straightforward for me yet, but at least 
I figured out how to do that sort of renaming in a way that doesn’t generate 
false positives.

As explained in the commit messages, if you run cmake you can specify 
-DCMAKE_CXX_COMPILER=/usr/bin/clazy ; if you run qmake you can configure with a 
clang platform, -no-pch QMAKE_CXX=clazy.  At least using it as a compiler 
wrapper is one way; there’s also clazy-standalone, but I was not having as much 
luck with that so far.  You want your build to include tests and examples too, 
so that they get checked (and fixed, to the extent possible).  Don’t use 
icecream or ccache, because it will bypass clazy.  The clazy-suggested fixes 
will generate a bunch of *.clazy.yaml files in the source tree (even if you are 
doing a shadow build, which I recommend, the yaml files go to the source 
directories).  Then you can go to the top of the module source and 
clang-apply-replacements . to apply those to the source files; git add -p to 
verify that each change is really a good one (and appropriate to be grouped in 
one patch); generate a commit and push it.  (The yaml files specify changes 
using byte offset, length, and replacement text, so that’s ephemeral obviously.)

I already generated patches for several more Qt 6 modules to take care of those 
event accessor deprecations so far.  But maybe it’s a good practice to do more 
of this, rather than applying API changes by hand.  When we add features to 
clazy, we will make it easier for users to port their code from Qt 5 to 6, too. 
 We could add something to the docs about that.

BTW one of its limitations seems to be that clang and clazy have to be in the 
same directory, so that's why I had to configure clazy with cmake 
-DCMAKE_INSTALL_PREFIX=/usr and sudo make install.   And so far I have not 
succeeded in using it on macOS, which I think is because of that limitation.  
It would be nice if that gets fixed somehow.

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

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

[Jean-Michaël Celerier]

Opening the root qt5/CMakeLists.txt has worked fine for me to work on e.g.
qt3d through QtCreator - did not really notice any performance penalty from
opening the whole project (except the initial "configure" step).

Kind regards,
Jean-Michaël



On Tue, Jun 9, 2020 at 10:05 AM Andy Nichols  wrote:

> Hi Alexandru,
>
> I think Brett touches on the biggest blocker for me and that is actually
> related to Qt Creators ability to open and use modules built using cmake.
> I am actually really impressed with state of the CMake support for build Qt
> as it is right now, and wish I could more actively use it, but
> unfortunately my current workflow involves using Qt Creator to develop Qt,
> and I have to work on modules that are not just QtBase.  Despite adding my
> cmake based Qt Builds to Creator as kits (which seems to only be possible
> using qmake), it isn't possible for Creator to easily recognize that my
> module's are built with that kit when loading them.  I hear rumors that it
> is possible, but most of the guys who say that are only working on qtbase
> anyway.
>
> I think that before we kill the qmake based build of Qt, that our own IDE
> should support developing Qt itself.  And I would be happy with some
> "sketchy config" that works with a released version of Qt Creator for now,
> but this shouldn't be good enough to justify killing qmake before a real
> solution is in place.
>
> Regards,
> Andy Nichols
>
> -Original Message-
> From: Development  On Behalf Of
> Stottlemyer, Brett (B.S.)
> Sent: Monday, June 8, 2020 6:48 PM
> To: Alexandru Croitor 
> Cc: Qt development mailing list 
> Subject: Re: [Development] Switch the main "Qt Build System"
>
> Hi Alexandru,
>
> Thanks for the quick reply.
>
> On 6/8/20, 12:09 PM, "Alexandru Croitor"  wrote:
>
> The current CMake configurations can be found in
> qt5.git/coin/platform_configs/qtsvg.yaml (and many other .yaml files there,
> it's just copy-pasted).
>
> Ahh, I didn't understand what these module specific versions were for.  I
> guess you download the dependencies (like qtbase) with the expected sha and
> same config, rather than building again?  That makes sense.
>
> There was an email on the development list about qt 6.0 module
> inclusion.
> https://clicktime.symantec.com/3Y88fCHSqah7h6p9gH8GzbV7Vc?u=https%3A%2F%2Fwiki.qt.io%2FChecklist_for_Qt_6.0_inclusion
>
> Yes, I'm aware.  That's where I see a lot of modules with no response or
> NOT READY as the status.
>
> If the module is not included (no cmake port), you can start using the
> dependencies.yaml mechanism to pin which sha1s of qtbase, declarative, etc
> to use, and continue building against those sha1s with qmake. Of course
> once the .pro files in qtbase are gone, you will be stuck to the last set
> of SHA1s that still have the .pro files. See dependencies.yaml in
> qtquickcontrols2.git for example.
>
> We have a qmake mixing mechanism (build qtremoteobjects with qmake
> against a qtbase built with CMake), but it's not 100% ready yet (the known
> issues are being fixed), and thus modules could continue to build with
> qmake against even newer sha1s, but I wouldn't bet too much on this
> approach (we tried our best to make it work, but there are bound to be
> corner cases even after we fix the known issues).
>
> I'll suggest "qmake mixing" be a prerequisite to flipping the switch to
> cmake.  It is hard enough to port to Qt6 with the binary
> incompatibilities.  If you make the build system side of this too painful
> as well, you risk modules not being carried to Qt6.  I know it is a
> different topic, but I am unable to open a developer build of qtbase (from
> cmake) in QtCreator - it wants to configure the project again (not to
> mention trying to get Ninja in the path for QtC on mac).  This all makes it
> hard to be an "early adopter", but doing the work later means you have to
> tackle all of these issues at once.  Without CI, presumably, after this
> change (at least for modules).
>
> I'm not arguing against the change, just want you guys to keep in mind
> what this is like for those of us that haven't been developing in Qt6 from
> the start.
>
> Thanks,
> Brett
>
> ___
> 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] Switch the main "Qt Build System"

[Alexandru Croitor]

> On 9. Jun 2020, at 10:17, Jean-Michaël Celerier 
>  wrote:
> 
> To simplify this step, is there / could there be maybe a 
> -DQT_BUILD_TOOLS_ONLY that would just generate... well, moc, uic, rcc and a 
> couple other friends required for a cross-build ?

I think that should technically be possible, but I have doubts about it.

Not all tools are "bootstrap" tools anymore, which means for uic you need to 
build QtCore (same for qmake actually).

I think qtdeclarative has tools that depend on QtQml.

So you'll have to have this weird hybrid of a Qt installation that needs to be 
maintained to work.

> 
> Best,
> Jean-Michaël
> 
> 
> On Tue, Jun 9, 2020 at 10:14 AM Alexandru Croitor  
> wrote:
> 
> 
> > On 9. Jun 2020, at 07:22, Bogdan Vatra  wrote:
> > 
> > - is it possible to cross compile Qt in one go (just like we do with qmake)?
> 
> Could you clarify what you mean by "in one go"?
> 
> If it's about building host tools as part of the cross-compilation, then no. 
> You first have to build a desktop Qt, and re-use that host Qt installation 
> for its tools, to cross-compile to another target.
> 
> That's been one of the goals for Qt 6 regardless of build system, and has 
> been communicated a while ago.

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

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

[Alexandru Croitor]

> On 9. Jun 2020, at 09:27, Shawn Rutledge  wrote:
> 
> FWIW the configuration mechanism seems a bit less friendly so far with all 
> those -DSHOUTED options like -DFEATURE_developer_build=ON instead of 
> configure -developer-build.  But there is cmake-gui, which generates 
> checkboxes for all the options after you have run cmake the first time.  They 
> are even searchable.  Is that a recommended way to discover the configure 
> options?  (Too bad you have to run cmake twice then.

Joerg already answered about this.

At least in my opinion, I think we should keep configure script because it's a 
nice developer interface. Some mappings are currently missing, but people could 
help us out there.

Indeed currently you need to run CMake at least once to get all the checkboxes. 
I have an idea of how we might improve that (so you don't have to run it once) 
but it's not done yet.

> 
> There will be no use for running the old configure script anymore then, right?

I think we should keep it.

> 
> It will work from the top-level, so we can still do chained builds with all 
> modules, right?

Yes. It's a bug if it doesn't.

> If you have done a build without tests or examples at first (for speed), and 
> then you want to build some specific ones, how do you do that?

You can use $qt_prefix/bin/qt-cmake-standalone-test to configure a single test 
(or subdir of tests), and build with ninja.
> 
> I see the same nice configure summary is still generated, but it would be 
> nice to keep writing that to a file like the old configure system does, for 
> later inspection.

I agree.

> 
> Will we keep using the configure.json files and generating configure.cmake 
> from them? 


It's possible, but it might make sense to to use configure.cmake as the source 
of truth as well. I don't believe we discussed that internally yet.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

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

[Jean-Michaël Celerier]

To simplify this step, is there / could there be maybe a
-DQT_BUILD_TOOLS_ONLY that would just generate... well, moc, uic, rcc and a
couple other friends required for a cross-build ?

Best,
Jean-Michaël


On Tue, Jun 9, 2020 at 10:14 AM Alexandru Croitor 
wrote:

>
>
> > On 9. Jun 2020, at 07:22, Bogdan Vatra  wrote:
> >
> > - is it possible to cross compile Qt in one go (just like we do with
> qmake)?
>
> Could you clarify what you mean by "in one go"?
>
> If it's about building host tools as part of the cross-compilation, then
> no. You first have to build a desktop Qt, and re-use that host Qt
> installation for its tools, to cross-compile to another target.
>
> That's been one of the goals for Qt 6 regardless of build system, and has
> been communicated a while ago.
> ___
> 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] Switch the main "Qt Build System"

[Alexandru Croitor]

> On 9. Jun 2020, at 07:22, Bogdan Vatra  wrote:
> 
> - is it possible to cross compile Qt in one go (just like we do with qmake)?

Could you clarify what you mean by "in one go"?

If it's about building host tools as part of the cross-compilation, then no. 
You first have to build a desktop Qt, and re-use that host Qt installation for 
its tools, to cross-compile to another target.

That's been one of the goals for Qt 6 regardless of build system, and has been 
communicated a while ago.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

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

[Alexandru Croitor]

> On 9. Jun 2020, at 04:32, André Pönitz  wrote:
> 
> On Mon, Jun 08, 2020 at 01:43:20PM +, Alexandru Croitor wrote:
>> [...]
>> The CMake ports are built in Coin with the most important configurations
>> (Linux, Windows, macOS, Android, iOS, qemu Linux).
> 
> Is there a list of configurations that work/do not work?

I'm not sure what your definition of works is.

Here you can see the configurations that are rested currently in Coin.

https://code.qt.io/cgit/qt/qt5.git/tree/coin/platform_configs/qtsvg.yaml (svg 
is just an example)

So desktop Ubuntu, static qt builds on Suse, macOS framework builds (non-fw 
also work), Windows MSVC2019, Windows MinGW 8, Android Arm64, iOS arm64.

I'm waiting on some updates to switch iOS to simulator_and_device.

Android multi-ABI is currently not implemented, and we don't plan to do it for 
6.0.

We don't have WebAssembly at the moment, but it was tested to work at some 
point.

Not shown here, we also have a Linux embedded arm qemu configuration in Coin 
for qtbase, which will be expanded to other modules.

> Will it be possible to use bisect "all of Qt" with reasonable effort also for 
> changes
> in the time until the transition is complete and the result is stable? E.g. 
> will
> there be clear which state of which module compiles with which state of other 
> modules
> with no or only short non-compilable phases inbetween?

If i understand correctly, this touches upon 2 topics.

1) if we remove .pro files, there will be 3 periods of build systems. Before 
6.0, you'll have to configure and build with qmake, then a short period where 
you can build with qmake and somewhat with cmake (depends on how far in the 
past you go and at what state the cmake port was in that time), and 
post-removal of .pro files, you'll only be able to build with cmake.

I don't think i can give you exact commit sets for that, so yes, it'll probably 
be painful.

2) dependencies.yaml

Which module compiles against which other module seems like a separate concern 
that is not entirely related to the build system in all cases.

Figuring out combos of which module sha1s can be built together is already 
somewhat of an issue with the current qmake build system, so that part is out 
of scope for the CMake port team.

Are you suggesting we somehow annotate the CMake part of the question? Like "we 
guarantee you can build qtbase, qtdeclarative, qtquickcontrols2 with CMake with 
SHAs X Y and Z? I'm not sure how useful that will be, given dev is constantly 
moving forward.

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

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

[Andy Nichols]

Hi Alexandru,

I think Brett touches on the biggest blocker for me and that is actually 
related to Qt Creators ability to open and use modules built using cmake.  I am 
actually really impressed with state of the CMake support for build Qt as it is 
right now, and wish I could more actively use it, but unfortunately my current 
workflow involves using Qt Creator to develop Qt, and I have to work on modules 
that are not just QtBase.  Despite adding my cmake based Qt Builds to Creator 
as kits (which seems to only be possible using qmake), it isn't possible for 
Creator to easily recognize that my module's are built with that kit when 
loading them.  I hear rumors that it is possible, but most of the guys who say 
that are only working on qtbase anyway.

I think that before we kill the qmake based build of Qt, that our own IDE 
should support developing Qt itself.  And I would be happy with some "sketchy 
config" that works with a released version of Qt Creator for now, but this 
shouldn't be good enough to justify killing qmake before a real solution is in 
place.

Regards,
Andy Nichols

-Original Message-
From: Development  On Behalf Of 
Stottlemyer, Brett (B.S.)
Sent: Monday, June 8, 2020 6:48 PM
To: Alexandru Croitor 
Cc: Qt development mailing list 
Subject: Re: [Development] Switch the main "Qt Build System"

Hi Alexandru,

Thanks for the quick reply.

On 6/8/20, 12:09 PM, "Alexandru Croitor"  wrote:

The current CMake configurations can be found in 
qt5.git/coin/platform_configs/qtsvg.yaml (and many other .yaml files there, 
it's just copy-pasted). 

Ahh, I didn't understand what these module specific versions were for.  I guess 
you download the dependencies (like qtbase) with the expected sha and same 
config, rather than building again?  That makes sense. 

There was an email on the development list about qt 6.0 module inclusion. 
https://clicktime.symantec.com/3Y88fCHSqah7h6p9gH8GzbV7Vc?u=https%3A%2F%2Fwiki.qt.io%2FChecklist_for_Qt_6.0_inclusion

Yes, I'm aware.  That's where I see a lot of modules with no response or NOT 
READY as the status.

If the module is not included (no cmake port), you can start using the 
dependencies.yaml mechanism to pin which sha1s of qtbase, declarative, etc to 
use, and continue building against those sha1s with qmake. Of course once the 
.pro files in qtbase are gone, you will be stuck to the last set of SHA1s that 
still have the .pro files. See dependencies.yaml in qtquickcontrols2.git for 
example.

We have a qmake mixing mechanism (build qtremoteobjects with qmake against 
a qtbase built with CMake), but it's not 100% ready yet (the known issues are 
being fixed), and thus modules could continue to build with qmake against even 
newer sha1s, but I wouldn't bet too much on this approach (we tried our best to 
make it work, but there are bound to be corner cases even after we fix the 
known issues).

I'll suggest "qmake mixing" be a prerequisite to flipping the switch to cmake.  
It is hard enough to port to Qt6 with the binary incompatibilities.  If you 
make the build system side of this too painful as well, you risk modules not 
being carried to Qt6.  I know it is a different topic, but I am unable to open 
a developer build of qtbase (from cmake) in QtCreator - it wants to configure 
the project again (not to mention trying to get Ninja in the path for QtC on 
mac).  This all makes it hard to be an "early adopter", but doing the work 
later means you have to tackle all of these issues at once.  Without CI, 
presumably, after this change (at least for modules).

I'm not arguing against the change, just want you guys to keep in mind what 
this is like for those of us that haven't been developing in Qt6 from the start.

Thanks,
Brett

___
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] Switch the main "Qt Build System"

[Kai Köhne]

> -Ursprüngliche Nachricht-
> Von: Development  Im Auftrag von
> [...]
> To build autotests, -DFEATURE_developer_build=ON will do that right?  And
> there are also BUILD_TESTING and QT_NO_MAKE_TESTS so what’s the
> relationship?

It's currently the same as with qt 5:

 *  FEATURE_developer_build does (among other things) enable tests 
(BUILD_TESTING) by default, for most platforms.
 * QT_NO_MAKE_TESTS defines whether a default build will build the tests; the 
default is OFF (so a mere ninja/jom ... will build all tests)

Question is whether this is actually what we want in Qt 6, see  
https://bugreports.qt.io/browse/QTBUG-84471 for some discussion.

Regards

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

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

[Joerg Bornemann]

On 6/9/20 9:27 AM, Shawn Rutledge wrote:


FWIW the configuration mechanism seems a bit less friendly so far with all 
those -DSHOUTED options like -DFEATURE_developer_build=ON instead of configure 
-developer-build.  But there is cmake-gui, which generates checkboxes for all 
the options after you have run cmake the first time.  They are even searchable. 
 Is that a recommended way to discover the configure options?  (Too bad you 
have to run cmake twice then.)


AFAICT this is currently the case. A more user-friendly way to discover 
Qt features is desirable.



There will be no use for running the old configure script anymore then, right?


The current configure script (on Linux) supports the -cmake switch and 
maps some (very few) arguments to CMake arguments. Like -feature-bla 
-DFEATURE_bla=ON


It seems that the classical configure interface is much nicer, 
especially for people who already know it. Everyone's invited to extend 
it to map the missing configure options. Same for the Windows configure.bat.



It will work from the top-level, so we can still do chained builds with all 
modules, right?


That's the plan. If it doesn't work, it's a bug.


To build autotests, -DFEATURE_developer_build=ON will do that right?  And there 
are also BUILD_TESTING and QT_NO_MAKE_TESTS so what’s the relationship?


BUILD_TESTING controls whether the tests are configured.
In a developer build this is set to ON by default.

BUILD_TESTING can be set explicitly to ON to enable tests in 
non-developer builds. BUILD_TESTING can be set explicitly to OFF to 
disable tests in developer builds.


The description of QT_NO_MAKE_TESTS is: "Should tests be built as part 
of the default 'all' target." Meaning this variable controls whether 
tests are build by default.


There's also a way to build stand-alone tests with the 
qt-cmake-standalone-test script in Qt's bin directory.



I see the same nice configure summary is still generated, but it would be nice 
to keep writing that to a file like the old configure system does, for later 
inspection.


True.

Will we keep using the configure.json files and generating configure.cmake from them? 


For now, the configure.json files are kept.


Then maybe we could write a better gui later on, that can show checkboxes 
before you run cmake the first time.  It could probably be a pure-qml 
implementation if we add a QProcess API (which a couple people have already 
tried to do over the years).


It could even have particle effects!


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

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

[Alexandru Croitor]

> On 8. Jun 2020, at 18:47, Stottlemyer, Brett (B.S.)  wrote:
> 
> Hi Alexandru,
> 
> Thanks for the quick reply.
> 
> On 6/8/20, 12:09 PM, "Alexandru Croitor"  wrote:
> 
>The current CMake configurations can be found in 
> qt5.git/coin/platform_configs/qtsvg.yaml (and many other .yaml files there, 
> it's just copy-pasted). 
> 
> Ahh, I didn't understand what these module specific versions were for.  I 
> guess you download the dependencies (like qtbase) with the expected sha and 
> same config, rather than building again?  That makes sense. 

The qtfoo.yaml files are used to declare the configuration (OS / compiler / 
arch) + configure flags. Those are used to configure qtbase, and build the rest 
of the dependencies, including your own module. The dependencies.yaml declares 
which sha1s of each repo to use. You can combine these to do whatever your 
module needs (extra configurations to test added or removed, specific sha1s).

> 
>There was an email on the development list about qt 6.0 module inclusion. 
> https://clicktime.symantec.com/3Y88fCHSqah7h6p9gH8GzbV7Vc?u=https%3A%2F%2Fwiki.qt.io%2FChecklist_for_Qt_6.0_inclusion
> 
> Yes, I'm aware.  That's where I see a lot of modules with no response or NOT 
> READY as the status.
> 
>If the module is not included (no cmake port), you can start using the 
> dependencies.yaml mechanism to pin which sha1s of qtbase, declarative, etc to 
> use, and continue building against those sha1s with qmake. Of course once the 
> .pro files in qtbase are gone, you will be stuck to the last set of SHA1s 
> that still have the .pro files. See dependencies.yaml in qtquickcontrols2.git 
> for example.
> 
>We have a qmake mixing mechanism (build qtremoteobjects with qmake against 
> a qtbase built with CMake), but it's not 100% ready yet (the known issues are 
> being fixed), and thus modules could continue to build with qmake against 
> even newer sha1s, but I wouldn't bet too much on this approach (we tried our 
> best to make it work, but there are bound to be corner cases even after we 
> fix the known issues).
> 
> I'll suggest "qmake mixing" be a prerequisite to flipping the switch to 
> cmake.  It is hard enough to port to Qt6 with the binary incompatibilities.  
> If you make the build system side of this too painful as well, you risk 
> modules not being carried to Qt6.  I know it is a different topic, but I am 
> unable to open a developer build of qtbase (from cmake) in QtCreator - it 
> wants to configure the project again (not to mention trying to get Ninja in 
> the path for QtC on mac).  This all makes it hard to be an "early adopter", 
> but doing the work later means you have to tackle all of these issues at 
> once.  Without CI, presumably, after this change (at least for modules).

I completely sympathise with the pain of porting. But we have to be pragmatic.

qmake mixing has been a goal for a long while, and we have spent an exorbitant 
amount of time on it, which in hindsight i think would have been better spent 
on the CMake port itself. 

We are fixing the known qmake mixing issues, and hopefully that can cover the 
usual cases. Unfortunately we can't spend more time on this due to limited time 
till Qt 6.0 release. 

Note that qmake mixing is not officially supported in the long run. qmake will 
support building applications and libraries, but not qt modules (qt_module.prf 
and friends). Otherwise we basically have to maintain two build system 
infrastructures (which we want to get away from).

Also note that developers were given time to port to CMake. And everyone that 
got stuck somewhere and needed help always received it (you are welcome at the 
#qt-cmake freenode channel).

I know Qt Creator currently has some quirks with the CMake workflow as well as 
the environment issues on macOS, but I can confirm that opening qtbase and 
friends is possible in Creator, albeit requiring some fiddling.

> 
> I'm not arguing against the change, just want you guys to keep in mind what 
> this is like for those of us that haven't been developing in Qt6 from the 
> start.
> 
> Thanks,
> Brett
> 

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

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

[Ville Voutilainen]

On Tue, 9 Jun 2020 at 10:35, Ville Voutilainen
 wrote:
>
> On Tue, 9 Jun 2020 at 10:29, Shawn Rutledge  wrote:
> >
> > FWIW the configuration mechanism seems a bit less friendly so far with all 
> > those -DSHOUTED options like -DFEATURE_developer_build=ON instead of 
> > configure -developer-build.  But there is cmake-gui, which generates 
> > checkboxes for all the options after you have run cmake the first time.  
> > They are even searchable.  Is that a recommended way to discover the 
> > configure options?  (Too bad you have to run cmake twice then.)
> >
> > There will be no use for running the old configure script anymore then, 
> > right?
>
> Last I looked, the configure script can configure a cmake build; it
> doesn't support all the options for cmake
> that it supports for qmake, but configure -developer-build certainly
> worked the last time I checked.

I mean configure -cmake -developer-build, of course :P
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

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

[Ville Voutilainen]

On Tue, 9 Jun 2020 at 10:29, Shawn Rutledge  wrote:
>
> FWIW the configuration mechanism seems a bit less friendly so far with all 
> those -DSHOUTED options like -DFEATURE_developer_build=ON instead of 
> configure -developer-build.  But there is cmake-gui, which generates 
> checkboxes for all the options after you have run cmake the first time.  They 
> are even searchable.  Is that a recommended way to discover the configure 
> options?  (Too bad you have to run cmake twice then.)
>
> There will be no use for running the old configure script anymore then, right?

Last I looked, the configure script can configure a cmake build; it
doesn't support all the options for cmake
that it supports for qmake, but configure -developer-build certainly
worked the last time I checked.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

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

[Joerg Bornemann]

On 6/9/20 7:22 AM, Bogdan Vatra via Development wrote:


- is it possible to cross compile Qt in one go (just like we do with qmake)?


Assuming you're talking about the multi-ABI Android build you've added 
to Qt5. This is not yet implemented, but certainly possible with the 
Ninja Multi-Config generator that has been added to CMake 3.17 [1].



- if you'll not support/trash all .pro/.pri files how we'll push fixes for 5.15
branch ? Because right now we can't push fixes directly to 5.15. branch and all
the fixes must go trough dev branch first.


All changes that do not apply to Qt6 must go to 5.15.
It's not true that we can't push fixes to 5.15 anymore.


BR,

Joerg

[1] https://blog.kitware.com/multi-config-ninja-generator-in-cmake-3-17/
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

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

[Shawn Rutledge]

FWIW the configuration mechanism seems a bit less friendly so far with all 
those -DSHOUTED options like -DFEATURE_developer_build=ON instead of configure 
-developer-build.  But there is cmake-gui, which generates checkboxes for all 
the options after you have run cmake the first time.  They are even searchable. 
 Is that a recommended way to discover the configure options?  (Too bad you 
have to run cmake twice then.)

There will be no use for running the old configure script anymore then, right?

It will work from the top-level, so we can still do chained builds with all 
modules, right?

To build autotests, -DFEATURE_developer_build=ON will do that right?  And there 
are also BUILD_TESTING and QT_NO_MAKE_TESTS so what’s the relationship?

If you have done a build without tests or examples at first (for speed), and 
then you want to build some specific ones, how do you do that?

I see the same nice configure summary is still generated, but it would be nice 
to keep writing that to a file like the old configure system does, for later 
inspection.

Will we keep using the configure.json files and generating configure.cmake from 
them?  Then maybe we could write a better gui later on, that can show 
checkboxes before you run cmake the first time.  It could probably be a 
pure-qml implementation if we add a QProcess API (which a couple people have 
already tried to do over the years).

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