ManuelSchneid3r
commented
6 years ago I never tried to inject data from the build script into the actual translation unit. It may be feasable but I see no gain there. This limitation is documented. Unless you develop albert, which means that the app root is likely to be somewhere in your $HOME, I see no reason to support anything else. We have the FHS. People will start to complain anyway if the FHS gets violated (we had this already).
I guess I know how you think. I also like to generalize things and keep them flexible to the maximum. But on the other side I learned to trade off time and other aspects.
Especially in this case I think to allow random CMAKE_PREFIXes which almost nobody uses is not worth the time finding an appropriate solution and adding a dependency to the buildscript. Imagine we would want to replace CMAKE, additions like these would make it a nightmare.
I dont think this is a good idea. Even if I reject the input here I want to thank you for your efforts, your contributions have always been absolute high quality stuff. Thank you for beeing part of albert.
Still I am open to discussions.
As noted in https://github.com/albertlauncher/albert/issues/640#issuecomment-374003867 and previous comments, albert is not possible to install into custom locations.
Albert still searches its hardcoded
/usr/paths for plugins. This results in weird issues, when specifying aCMAKE_INSTALL_PREFIX. Albert fails to start after successful compilation and installation.But if albert is compiled and installed again with
-DCMAKE_INSTALL_PREFIX=/usr, the one with the custom path works, too.Wouldn't it be possible to respect and give precedence to the
CMAKE_INSTALL_PREFIXhere?https://github.com/albertlauncher/albert/blob/49de9caac811bf41256e131013a8f50debe0b4e3/lib/albertcore/src/core/albert.cpp#L264-L287