3rdparty: fix LibMyPaint failing CI on Windows
In a previous MR (!594 (merged)) I upgraded boud's patch for LibMyPaint's build toolchain in Windows. However, ever since then nightly builds for Windows have been failing consistently at LibMyPaint's configure step:
13:28:08 CMake Error at CMakeLists.txt:67 (install):
13:28:08 install Library TARGETS given no DESTINATION!
13:28:08
13:28:08
13:28:08 -- Configuring incomplete, errors occurred!
13:28:08 See also "C:/Packaging/KritaDepsBuild/ext_mypaint/ext_mypaint-prefix/src/ext_mypaint-build/CMakeFiles/CMakeOutput.log".
(from https://binary-factory.kde.org/job/Krita_Nightly_Windows_Dependency_Build/173/execution/node/17/log/ )
What I had not noticed (nor I could figure out, until I grep'd the binary factory log) was that KDE runs CMake 3.13.2, and I had unintentionally used a feature only available on CMake 3.14 and later:
The install(FILES) and install(DIRECTORY) commands learned a new set of parameters for installing files as a file type, setting the destination based on the appropriate variables from GNUInstallDirs and built-in defaults, in lieu of a DESTINATION argument.
(source: https://cmake.org/cmake/help/latest/release/3.14.html#commands)
This commit restores boud's original folders, while using the parameters defined by KDEInstallDirs.
CCMAIL: kimageshop@kde.org
Test Plan
Build LibMyPaint on all OSes.
Formalities Checklist
-
I confirmed this builds. -
I confirmed Krita ran and the relevant functions work. -
I tested the relevant unit tests and can confirm they are not broken. (If not possible, don't hesitate to ask for help!) -
I made sure my commits build individually and have good descriptions as per KDE guidelines. -
I made sure my code conforms to the standards set in the HACKING file. -
I can confirm the code is licensed and attributed appropriately, and that unattributed code is mine, as per KDE Licensing Policy.