> Would that help ?<br>
> If the package would be installed to the prefix /usr/, but /usr/lib/ was a<br>
> symlink to /lib64/, there would be the same problem I think.<br><br>Fair enough.<br><br>
<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">the idea is that the Config.cmake file knows where the needed files are, so it<br>
doesn't actually have to search.<br>
<br>
Using absolute paths is bad, because then the package can't be relocated. At<br>
least under Windows and OSX this is absolutely necessary.<br>
So relative paths are used.<br>
<br>
When using cmake 2.8.8 or newer, the macro configure_package_config_file()<br>
should be used for creating those Config.cmake files.<br>
They would still fail, but at least they would give a better error message,<br>
which would have been<br>
Automoc4Config.cmake: "File or directory /bin/automoc4 referenced by variable<br>
AUTOMOC4_EXECUTABLE does not exist !"<br></blockquote><div><br>In my opinion, we cannot lose potential contributors, so this should be fixed centrally. Currently, people would need to apply a symlink workaround to be able to contribute to such KDE projects where it applies (i.e. not qt only projects).<br>
<br>Couldn't the PATH search be a fallback if nothing else works? Do you have a better approach to fix this issue centrally and aid the KDE contribution?<br><br>Laszlo <br></div></div><br>