[Development] Switch the main "Qt Build System"

[Matthew Woehlke]

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