[Interest] Qt 5.12.3 build generates absolute library paths in .prl files

[Michal Klocek]

Hi

see https://codereview.qt-project.org/#/c/212562/
and for some discussions  https://bugreports.qt.io/browse/QTBUG-72903

Br

Michal

On 5/8/19 10:52 AM, Simon Holmberg wrote:
> I'm not well versed in qmake, nor could I find much information about 
> the .prl files that qmake generates along with its library outputs. But 
> as I've understood it, they are generated so that future linking against 
> the Qt libraries (when using qmake) will know which additional library 
> dependencies are needed.
> 
> This has apparently been working fine in the past for us, where a .prl 
> file would look like this:
> 
>     [...]
>     QMAKE_PRL_VERSION = 5.10.1
>     QMAKE_PRL_LIBS = -lmpr -lnetapi32 -luserenv -lversion -lws2_32
>     -lkernel32 -luser32 -lshell32 -luuid -lole32 -ladvapi32 -lwinmm
>     -L$$[QT_INSTALL_LIBS] $$[QT_INSTALL_LIBS]\\qtpcre2.lib
> 
> 
> This is all fine and dandy. However, after attempting to upgrade to 
> 5.12.3, the generated .prl's now look like this for us:
> 
>     [...]
>     QMAKE_PRL_VERSION = 5.12.3
>     QMAKE_PRL_LIBS =
>     C:\\Needy\\cache\\3rdparty\\WinSDK\\WinSDK-10.0.17134.0.1.1.1.1452640\\Win64\\10\\Lib\\10.0.17134.0\\um\\x64\\mpr.lib
>     C:\\Needy\\cache\\3rdparty\\WinSDK\\WinSDK-10.0.17134.0.1.1.1.1452640\\Win64\\10\\Lib\\10.0.17134.0\\um\\x64\\netapi32.lib
>     C:\\Needy\\cache\\3rdparty\\WinSDK\\WinSDK-10.0.17134.0.1.1.1.1452640\\Win64\\10\\Lib\\10.0.17134.0\\um\\x64\\userenv.lib
>     C:\\Needy\\cache\\3rdparty\\WinSDK\\WinSDK-10.0.17134.0.1.1.1.1452640\\Win64\\10\\Lib\\10.0.17134.0\\um\\x64\\version.lib
>     C:\\Needy\\cache\\3rdparty\\WinSDK\\WinSDK-10.0.17134.0.1.1.1.1452640\\Win64\\10\\Lib\\10.0.17134.0\\um\\x64\\ws2_32.lib
>     C:\\Needy\\cache\\3rdparty\\WinSDK\\WinSDK-10.0.17134.0.1.1.1.1452640\\Win64\\10\\Lib\\10.0.17134.0\\um\\x64\\kernel32.lib
>     C:\\Needy\\cache\\3rdparty\\WinSDK\\WinSDK-10.0.17134.0.1.1.1.1452640\\Win64\\10\\Lib\\10.0.17134.0\\um\\x64\\user32.lib
>     C:\\Needy\\cache\\3rdparty\\WinSDK\\WinSDK-10.0.17134.0.1.1.1.1452640\\Win64\\10\\Lib\\10.0.17134.0\\um\\x64\\shell32.lib
>     C:\\Needy\\cache\\3rdparty\\WinSDK\\WinSDK-10.0.17134.0.1.1.1.1452640\\Win64\\10\\Lib\\10.0.17134.0\\um\\x64\\uuid.lib
>     C:\\Needy\\cache\\3rdparty\\WinSDK\\WinSDK-10.0.17134.0.1.1.1.1452640\\Win64\\10\\Lib\\10.0.17134.0\\um\\x64\\ole32.lib
>     C:\\Needy\\cache\\3rdparty\\WinSDK\\WinSDK-10.0.17134.0.1.1.1.1452640\\Win64\\10\\Lib\\10.0.17134.0\\um\\x64\\advapi32.lib
>     C:\\Needy\\cache\\3rdparty\\WinSDK\\WinSDK-10.0.17134.0.1.1.1.1452640\\Win64\\10\\Lib\\10.0.17134.0\\um\\x64\\winmm.lib
>     $$[QT_INSTALL_LIBS]/qtpcre2.lib
> 
> 
> All library paths are now absolute paths! Why is this? Is there some 
> compilation flag I can use to disable this behaviour?
> This is causing us great pain in building PyQt when linking with our 
> local build of Qt, since the libraries needed to build are in completely 
> different locations on our build machines.
> This article mentions 
> <https://doc.qt.io/qt-5/qmake-advanced-usage.html#library-dependencies> 
> the .prl files not being portable between platforms, but surely they're 
> intended to be between machines?
> 
> Thanks!
> 
> 
> 
> 
> 
> **Simon HolmbergI Graduate Tools Programmer**
> 
> *AVALANCHE STUDIOS*
> *Malmö*I *Stockholm**I New York*
> 
> _______________________________________________
> Interest mailing list
> Interest at qt-project.org
> https://lists.qt-project.org/listinfo/interest
>