On Sunday 18 November 2012, Laszlo Papp wrote: > > Would that help ? > > If the package would be installed to the prefix /usr/, but /usr/lib/ was > > a symlink to /lib64/, there would be the same problem I think. > > Fair enough. > > the idea is that the Config.cmake file knows where the needed files are, so > > > it > > doesn't actually have to search. > > > > Using absolute paths is bad, because then the package can't be relocated. > > At > > least under Windows and OSX this is absolutely necessary. > > So relative paths are used. > > > > When using cmake 2.8.8 or newer, the macro > > configure_package_config_file() should be used for creating those > > Config.cmake files. > > They would still fail, but at least they would give a better error > > message, which would have been > > Automoc4Config.cmake: "File or directory /bin/automoc4 referenced by > > variable > > AUTOMOC4_EXECUTABLE does not exist !" > > 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).
This happens potentially for all projects which install a Config.cmake file and/or install a file containing exported targets. > 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? I started a thread on cmake-devel. Alex _______________________________________________ Kde-buildsystem mailing list [email protected] https://mail.kde.org/mailman/listinfo/kde-buildsystem
