> On 2020 Jun 9, at 11:05, Alexandru Croitor <[email protected]> wrote: > >> On 9. Jun 2020, at 10:38, Shawn Rutledge <[email protected]> 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 [email protected] https://lists.qt-project.org/listinfo/development
