Multiplatform frameworks

[Aleix Pol]

On Thu, Feb 26, 2015 at 3:10 AM, Jeremy Whiting <jpwhiting at kde.org> wrote:
> 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
>

Hi Jeremy,
Thanks a lot for looking into this, I think it's very interesting!

So what CMAKE_INSTALL_PREFIX are you setting on your applications?
That's /usr/local? Maybe that doesn't make sense in OS X?
I'd suggest you to play a bit with
modules/ECMPackageConfigHelpers.cmake so we can find what's exactly
the odd part...

Aleix