[Development] Switch the main "Qt Build System"

[Joerg Bornemann]

On 6/9/20 9:27 AM, 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.  They are even searchable.  Is that a recommended way to discover the configure options?  (Too bad you have to run cmake twice then.)

AFAICT this is currently the case. A more user-friendly way to discover 
Qt features is desirable.

> There will be no use for running the old configure script anymore then, right?

The current configure script (on Linux) supports the -cmake switch and 
maps some (very few) arguments to CMake arguments. Like -feature-bla 
-DFEATURE_bla=ON

It seems that the classical configure interface is much nicer, 
especially for people who already know it. Everyone's invited to extend 
it to map the missing configure options. Same for the Windows configure.bat.

> It will work from the top-level, so we can still do chained builds with all modules, right?

That's the plan. If it doesn't work, it's a bug.

> To build autotests, -DFEATURE_developer_build=ON will do that right?  And there are also BUILD_TESTING and QT_NO_MAKE_TESTS so what’s the relationship?

BUILD_TESTING controls whether the tests are configured.
In a developer build this is set to ON by default.

BUILD_TESTING can be set explicitly to ON to enable tests in 
non-developer builds. BUILD_TESTING can be set explicitly to OFF to 
disable tests in developer builds.

The description of QT_NO_MAKE_TESTS is: "Should tests be built as part 
of the default 'all' target." Meaning this variable controls whether 
tests are build by default.

There's also a way to build stand-alone tests with the 
qt-cmake-standalone-test script in Qt's bin directory.

> 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.

True.

> Will we keep using the configure.json files and generating configure.cmake from them? 

For now, the configure.json files are kept.

> Then maybe we could write a better gui later on, that can show checkboxes before you run cmake the first time.  It could probably be a pure-qml implementation if we add a QProcess API (which a couple people have already tried to do over the years).

It could even have particle effects!


Joerg