Re: Multiplatform frameworks
On Friday 27 February 2015 22:55:18 Alex Merry wrote: On Friday 27 February 2015 13:29:59 Jeremy Whiting wrote: On Fri, Feb 27, 2015 at 4:05 AM, Alex Merry alex.me...@kde.org wrote: 4. Use the PATH_VARS to ecm_configure_package_config_file(). ecm_configure_package_config_file() behaves like configure_package_config_file from CMake 3.0, so see http://www.cmake.org/cmake/help/v3.1/module/CMakePackageConfigHelpers.ht ml Basically, you add KDE_INSTALL_DATADIR to the PATH_VARS argument of ecm_configure_package_config_file(), and use @PACKAGE_KDE_INSTALL_DATADIR@ in your Config.cmake.in file, and it should all work. This is now implemented across frameworks. I haven't touched any libraries outside frameworks, though. Alex
Re: Multiplatform frameworks
Alex,
On Fri, Feb 27, 2015 at 4:05 AM, Alex Merry alex.me...@kde.org wrote:
On Wednesday 25 February 2015 19:10:08 Jeremy Whiting wrote:
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}
I'd rather avoid this approach - too easy to let the files get out of sync.
I agree.
2. Inside KF5FooConfig.cmake.in have platform detection to define
whether
to use the prefix or not.
This is a lot of noise, and hard to check.
Agreed.
3. Use absolute paths for KDE_INSTALL_DATADIR everywhere and remove
${PACKAGE_PREFIX_PATH} completely.
There is KDE_INSTALL_FULL_DATADIR, which is absolute. However, that removes
the relocatability of the package that ${PACKAGE_PREFIX_PATH} provides. I'm
not sure just how much we care about that.
How is that set, just at the command line with -DKDE_INSTALL_FULL_DATADIR
or I also saw some IS_RELATIVE in the code that set FULL_* if the path is
absolute, though I couldn't get that to trigger here somehow.
4. Use the PATH_VARS to ecm_configure_package_config_file().
ecm_configure_package_config_file() behaves like
configure_package_config_file from
CMake 3.0, so see
http://www.cmake.org/cmake/help/v3.1/module/CMakePackageConfigHelpers.html
Basically, you add KDE_INSTALL_DATADIR to the PATH_VARS argument of
ecm_configure_package_config_file(), and use @PACKAGE_KDE_INSTALL_DATADIR@
in
your Config.cmake.in file, and it should all work.
This sounds like the best option, could you throw together a patch to
kdoctools KF5KDocTools.ConfigCmake.cmake.in showing how that works? My
cmake foo is ok, but it would probably take me longer to do this than
someone that works with CMake every day.
Alex
Re: Multiplatform frameworks
On Wednesday 25 February 2015 19:10:08 Jeremy Whiting wrote:
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}
I'd rather avoid this approach - too easy to let the files get out of sync.
2. Inside KF5FooConfig.cmake.in have platform detection to define whether
to use the prefix or not.
This is a lot of noise, and hard to check.
3. Use absolute paths for KDE_INSTALL_DATADIR everywhere and remove
${PACKAGE_PREFIX_PATH} completely.
There is KDE_INSTALL_FULL_DATADIR, which is absolute. However, that removes
the relocatability of the package that ${PACKAGE_PREFIX_PATH} provides. I'm
not sure just how much we care about that.
4. Use the PATH_VARS to ecm_configure_package_config_file().
ecm_configure_package_config_file() behaves like configure_package_config_file
from
CMake 3.0, so see
http://www.cmake.org/cmake/help/v3.1/module/CMakePackageConfigHelpers.html
Basically, you add KDE_INSTALL_DATADIR to the PATH_VARS argument of
ecm_configure_package_config_file(), and use @PACKAGE_KDE_INSTALL_DATADIR@ in
your Config.cmake.in file, and it should all work.
Alex
Re: Multiplatform frameworks
On Friday 27 February 2015 13:29:59 Jeremy Whiting wrote:
3. Use absolute paths for KDE_INSTALL_DATADIR everywhere and remove
${PACKAGE_PREFIX_PATH} completely.
There is KDE_INSTALL_FULL_DATADIR, which is absolute. However, that
removes
the relocatability of the package that ${PACKAGE_PREFIX_PATH} provides.
I'm
not sure just how much we care about that.
How is that set, just at the command line with -DKDE_INSTALL_FULL_DATADIR
or I also saw some IS_RELATIVE in the code that set FULL_* if the path is
absolute, though I couldn't get that to trigger here somehow.
If KDE_INSTALL_DATADIR is absolute, KDE_INSTALL_FULL_DATADIR will be set to
it. If not, KDE_INSTALL_DATADIR will be set to
CMAKE_INSTALL_PREFIX/KDE_INSTALL_DATADIR.
4. Use the PATH_VARS to ecm_configure_package_config_file().
ecm_configure_package_config_file() behaves like
configure_package_config_file from
CMake 3.0, so see
http://www.cmake.org/cmake/help/v3.1/module/CMakePackageConfigHelpers.html
Basically, you add KDE_INSTALL_DATADIR to the PATH_VARS argument of
ecm_configure_package_config_file(), and use @PACKAGE_KDE_INSTALL_DATADIR@
in
your Config.cmake.in file, and it should all work.
This sounds like the best option, could you throw together a patch to
kdoctools KF5KDocTools.ConfigCmake.cmake.in showing how that works? My
cmake foo is ok, but it would probably take me longer to do this than
someone that works with CMake every day.
Yep, I'll aim to do that tomorrow.
Alex
Re: Multiplatform frameworks
On Thu, Feb 26, 2015 at 3:10 AM, Jeremy Whiting jpwhit...@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
