Change Details

Qt cmake currently does an optional find of all the modules, if they're not available it temporarily disabled ENABLE_QT5, and gives a nice message rather than just breaking. It seems that there was an attempt to only do this if QT5 is not explicitly defined, but that test was broken. On the first run the option is not set, so it is not defined, on the second run it's loaded from the cache and therefore is defined to the previous default value. So you always get a nasty error on the second cmake run. Setting the default value of an option based on whether it's defined or not is uneccasary cmake does that for us. I've also ported the case of only enabling kde support when we link KDE when we build the relevant Qt to a cmake function that handles it all for us. It allows the user to set an option explicitly and it will be remembered, but the variable will only be true if and only if Qt is also found.

Qt cmake currently does an optional find of all the modules, if they're not available it temporarily disables ENABLE_QT5, and gives a nice message rather than just breaking. It seems that there was an attempt to only do this if ENABLE_QT5 is not explicitly defined, but that test is flawed. There is no way to tell the difference between loading from a previous cache and the command line as -D is literally just setting a cache variable before it starts processing. On the first run it fails gracefully, on a second cmake run, it then just breaks badly. --- I've also ported the case of only enabling kde support when we link KDE when we build the relevant Qt to a cmake function that handles it all for us. It allows the user to set an option explicitly and it will be remembered, but the variable will only be true if and only if Qt is also found.

Qt cmake currently does an optional find of all the modules, if they're not available it temporarily disableds ENABLE_QT5, and gives a nice message rather than just breaking. It seems that there was an attempt to only do this if QT5 is not explicitly defined, but that test was broken. On the first run the option is not set, so it is not defined, on the second run it's loaded from the cache and therefore is defined to the previous default value.ENABLE_QT5 is not So you always get a nasty error on the second cmake runexplicitly defined, but that test is flawed. There is no way to tell the difference between loading from a previous cache and the command line as -D is literally just setting a cache variable before it starts processing. SettingOn the default value of an option basedfirst run it fails gracefully, on whether it's defined or not is uneccasary cmake does that for us.a second cmake run, it then just breaks badly. --- I've also ported the case of only enabling kde support when we link KDE when we build the relevant Qt to a cmake function that handles it all for us. It allows the user to set an option explicitly and it will be remembered, but the variable will only be true if and only if Qt is also found.