Multiplatform frameworks

[Jeremy Whiting]

Hello core developers,

In the past few months some effort has been made to get the frameworks
(kf5) to work on other platforms such as OS X and Windows. Together with
Marko I focused primarily on OS X since there was already a patch for
QStandardPaths there that worked pretty well. In discussion with the Qt
developers I began to think that we maybe should be installing our data
files in the places that QStandardPaths expect to find them, rather than
get QStandardPaths to find files in linuxy paths.

Yesterday I did a test to see if I could get our data files to install to
the places that QStandardPaths looks for them. All I had to do was pass
-DCMAKE_INSTALL_DATADIR="/Users/jeremy/Library/Application Support/" to
cmake (I added it in my .kdesrc-buildrc actually) and most of the
frameworks built just fine with vanilla Qt 5.4.1. Actually even kanagram
and khangman which required the QSP patch to run ran fine after I built kde
with that one change.

One issue I found however is that some frameworks (maybe all?) have a
KF5FooConfig.cmake.in with ${PACKAGE_PREFIX_PATH}/@KDE_INSTALL_DATADIR@ in
them to specify where to find the data files. On my OS X install that was
getting filled in as "/usr/local/Users/jeremy/Library/Application Support"
which is incorrect. It seems on linux KDE_INSTALL_DATADIR is a subpath of
the prefix, but that doesn't work if we are installing data files outside
the prefix. So how should/could this be solved? I can think of three ideas:

1. Add another .cmake.in specifically for platforms that install data files
outside the prefix such as KF5FooMacConfig.cmake.in which is used on OS X
to generate the KF5FooConfig.cmake and doesn't include
${PACKAGE_PREFIX_PATH}
2. Inside KF5FooConfig.cmake.in have platform detection to define whether
to use the prefix or not.
3. Use absolute paths for KDE_INSTALL_DATADIR everywhere and remove
${PACKAGE_PREFIX_PATH} completely.

I'm not sure which approach would be best, but any would be a step closer
to working better on other platforms.

BR,
Jeremy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20150225/6188b90f/attachment.htm>