Actual problem was introduced by this commit https://qt.gitorious.org/qt/qtbase/commit/be1116fe909a60341f714d5ce0765798a08722e7 in short if we have CONFIG += depend_prl, a project won't build with Qt5. upstream changed meaning of depend_prl and introduced fast_depend_prl. I believe the proper way to solve this is removing QMAKE_PRL_BUILD_DIR from installed *.prl files. easy way to fix qt5 installation: for f in /usr/lib64/*.prl; do sed '/QMAKE_PRL_BUILD_DIR/d' -i $f; done Reproducible: Always Steps to Reproduce: echo "CONFIG += depend_prl" > test.pro /usr/lib64/qt5/bin/qmake test.pro Actual Results: generated Makefile forces rebuilding of Qt5 libraries in not existing paths Expected Results: generated Makefile does not try to rebuild Qt5 libraries.
(In reply to Rion from comment #0) > in short if we have CONFIG += depend_prl, a project won't build with Qt5. Give an example of a project that uses depend_prl. I don't think you're supposed to use it in your project.
net-im/psi
hm just checked documentation. depend_prl is undocumented and therefore probably shouldn't be used. in case of psi, most likely it should be replaced by link_prl. in any case that's strange to have those not existing paths in *.prl files which may break compilation.
(In reply to Rion from comment #3) > hm just checked documentation. depend_prl is undocumented and therefore > probably shouldn't be used. > > in case of psi, most likely it should be replaced by link_prl. > Yes, link_prl is what I've seen in other projects. > in any case that's strange to have those not existing paths in *.prl files > which may break compilation. I agree in principle, but if depend_prl is indeed "for internal usage only", this point becomes moot.
I consider this invalid. If psi is misusing depend_prl, file a bug against that package. This is not a qt bug.
