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 [email protected] https://lists.qt-project.org/listinfo/development
