Re-enable build with external QtOAuth
Review Request #129927 - Created Feb. 5, 2017 and discarded
This reverts commit ff4b966f13b1b8da8471f92f44751b58012a53e8.
And partially reverts commit 7b6937326ba2a4e4072692add38a4abd28bd0cd4
so that kbibtex is using system-qoauth instead of bundled one. Gentoo has been building kbibtex master the past few months like that without obvious issues.
|I would like to see a fallback to the already existing/bundled qoauth code, unless you can argue that every major ...||Thomas Fischer|
|Why is it necessary to add QTOAUTH_INCLUDE_DIR here?||Thomas Fischer|
|What is the point of cmake_2_8_12_PRIVATE here? I know that it was there in the old code, but is it ...||Thomas Fischer|
Major issue: This will break the existing behavior by introducing a new dependency (to an externally installed QtOAuth/Qt5). That would be ok if either a fallback to the bundled QtOAuth is used in case there is no system-wide installation of QtOAuth or if it can be argued that QtOAuth for Qt5 will be available in all major Linux distributions. Generally, this code path may need to be revised anyway once Qt 5.9 ships with its "Network Authentication" supporting both OAuth 1 and 2 (currently Tech Preview in Qt 5.8). This means that QtOAuth needs to be continued to be supported for pre-5.9 installations as well as a new code path for installations with Qt 5.9+ without an external QtOAuth.
I would like to see a fallback to the already existing/bundled qoauth code, unless you can argue that every major distribution provides packages for qtoauth 2.x, i.e. the Qt5-based one.
Why is it necessary to add QTOAUTH_INCLUDE_DIR here?
What is the point of cmake_2_8_12_PRIVATE here? I know that it was there in the old code, but is it necessary for a modern CMake 3.x?