On Monday February 25 2019 12:24:31 Kevin Funk wrote: > That makes sense in theory. QMake will switch to a different mkspec when you > pass `-spec ...` when building an external project. It's impossible to > instruct CMake to do the same right now, as the mkspec is hardcoded in the > CMake config files of the Qt install. > > Maybe there should be a way to overwrite the mkspec used via a -DQT_MKSPEC > parameter, with the potential drawback of being able to create a broken
I'm testing a patch which leaves in the CMAKE_MKSPEC variable (with the current hardcoded setting as a default). So far I haven't noticed any differences but I haven't yet pushed things to the limit. CMake gives the user plenty of opportunity to create a broken configuration; as long as any new option complies with the "garbage in/out" principle there shouldn't be a problem :) > be a potential solution, but again, would require quite a lot of additional > CMake code I'm afraid. Not something I'd envision to maintain for all the > different mkspecs we have. You could consider an approach where you do a reasonable amount of inferring for the foreseeable configurations, and raise an error requiring the user to set the variable explicitly when there's a too big mismatch with the Qt build configuration. No idea if that's better than just using the current hardcoded default with a possibility for manual override. > Yes, that's why this hasn't popped up on the bug tracker so far I think. It's > again an artificial problem: Maybe, but one that can become a real problem anytime. Probably. So maybe my example was too good in a sense (it's been too long since I did any development on MSWin), but what when one of the mkspec headers introduces something that somehow depends on the C++ runtime in use (on Linux; here too I'm not certain if it is officially "not done" but libc++ appears to be mixable with libstdc++ when built against that runtime)? R _______________________________________________ Development mailing list [email protected] https://lists.qt-project.org/listinfo/development
