<div dir="ltr">Alex,<br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Feb 27, 2015 at 4:05 AM, Alex Merry <span dir="ltr"><<a href="mailto:alex.merry@kde.org" target="_blank">alex.merry@kde.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Wednesday 25 February 2015 19:10:08 Jeremy Whiting wrote:<br>
> One issue I found however is that some frameworks (maybe all?) have a<br>
> <a href="http://KF5FooConfig.cmake.in" target="_blank">KF5FooConfig.cmake.in</a> with ${PACKAGE_PREFIX_PATH}/@KDE_INSTALL_DATADIR@ in<br>
> them to specify where to find the data files. On my OS X install that was<br>
> getting filled in as "/usr/local/Users/jeremy/Library/Application Support"<br>
> which is incorrect. It seems on linux KDE_INSTALL_DATADIR is a subpath of<br>
> the prefix, but that doesn't work if we are installing data files outside<br>
> the prefix. So how should/could this be solved? I can think of three ideas:<br>
><br>
> 1. Add another .<a href="http://cmake.in" target="_blank">cmake.in</a> specifically for platforms that install data files<br>
> outside the prefix such as <a href="http://KF5FooMacConfig.cmake.in" target="_blank">KF5FooMacConfig.cmake.in</a> which is used on OS X<br>
> to generate the KF5FooConfig.cmake and doesn't include<br>
> ${PACKAGE_PREFIX_PATH}<br>
<br>
</span>I'd rather avoid this approach - too easy to let the files get out of sync.<br></blockquote><div>I agree. </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
> 2. Inside <a href="http://KF5FooConfig.cmake.in" target="_blank">KF5FooConfig.cmake.in</a> have platform detection to define whether<br>
> to use the prefix or not.<br>
<br>
</span>This is a lot of noise, and hard to check.<br></blockquote><div>Agreed. </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
> 3. Use absolute paths for KDE_INSTALL_DATADIR everywhere and remove<br>
> ${PACKAGE_PREFIX_PATH} completely.<br>
<br>
</span>There is KDE_INSTALL_FULL_DATADIR, which is absolute. However, that removes<br>
the relocatability of the package that ${PACKAGE_PREFIX_PATH} provides. I'm<br>
not sure just how much we care about that.<br></blockquote><div>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. </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
4. Use the PATH_VARS to ecm_configure_package_config_file().<br>
<br>
ecm_configure_package_config_file() behaves like configure_package_config_file from<br>
CMake 3.0, so see<br>
<a href="http://www.cmake.org/cmake/help/v3.1/module/CMakePackageConfigHelpers.html" target="_blank">http://www.cmake.org/cmake/help/v3.1/module/CMakePackageConfigHelpers.html</a><br>
<br>
Basically, you add KDE_INSTALL_DATADIR to the PATH_VARS argument of<br>
ecm_configure_package_config_file(), and use @PACKAGE_KDE_INSTALL_DATADIR@ in<br>
your <a href="http://Config.cmake.in" target="_blank">Config.cmake.in</a> file, and it should all work.<br></blockquote><div><br></div><div>This sounds like the best option, could you throw together a patch to kdoctools <a href="http://KF5KDocTools.ConfigCmake.cmake.in">KF5KDocTools.ConfigCmake.cmake.in</a> 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.</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class="HOEnZb"><font color="#888888"><br>
Alex<br>
<br>
<br>
</font></span></blockquote></div><br></div></div>