[Development] Switch the main "Qt Build System"
alexandru.croitor at qt.io
Tue Jun 9 14:57:07 CEST 2020
> 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.
More information about the Development