[Development] Switch the main "Qt Build System"
mwoehlke.floss at gmail.com
Tue Jun 9 16:38:04 CEST 2020
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
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
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.
More information about the Development