> On 9. Jun 2020, at 09:27, Shawn Rutledge <[email protected]> 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.
Joerg already answered about this. At least in my opinion, I think we should keep configure script because it's a nice developer interface. Some mappings are currently missing, but people could help us out there. Indeed currently you need to run CMake at least once to get all the checkboxes. I have an idea of how we might improve that (so you don't have to run it once) but it's not done yet. > > There will be no use for running the old configure script anymore then, right? I think we should keep it. > > It will work from the top-level, so we can still do chained builds with all > modules, right? Yes. It's a bug if it doesn't. > 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? You can use $qt_prefix/bin/qt-cmake-standalone-test to configure a single test (or subdir of tests), and build with ninja. > > 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 agree. > > Will we keep using the configure.json files and generating configure.cmake > from them? It's possible, but it might make sense to to use configure.cmake as the source of truth as well. I don't believe we discussed that internally yet. _______________________________________________ Development mailing list [email protected] https://lists.qt-project.org/listinfo/development
