[Development] Switch the main "Qt Build System"

[Alexandru Croitor]

> On 9. Jun 2020, at 13:20, Shawn Rutledge <Shawn.Rutledge at qt.io> wrote:
> 
> 
>> On 2020 Jun 9, at 11:05, Alexandru Croitor <alexandru.croitor at qt.io> wrote:
>> 
>>> On 9. Jun 2020, at 10:38, Shawn Rutledge <Shawn.Rutledge at qt.io> 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.