Patch *.prl too and patch *.pc for mingw

[iakov]

*.prl are qmake's library descriptions like *.pc are for package-config, and contain incorrect paths for some archives/modules (at least qttools is bad in 5.11)

Also .pc can be used with mingw via MSYS's pkgconfig, and should be patched on Windows too.

[iakov]

I experienced g++: error: c:\Users\qt\work\install\lib\libQt5Widgets.a: No such file or directory
https://github.com/iakov/pythonqt/actions/runs/4075077557/jobs/7020997662#step:9:30484

[iakov]

Waiting for #641 to be merged to rebase.

[iakov]

CI build fails with Failed to locate XML data for Qt version '5.14.2'.
Maybe a temporary problem, please, re-run a single job if there is such a possibility.

[ddalcino]

I wouldn't worry about the CI failure; that's probably a server backpressure mechanism.

The only thing I can see that this PR is lacking is additional tests. I think it's clear that it's not going to break any existing functionality, but I would like to see proof in CI that this change is fixing something, and a way to prevent regressions in the future.

For now, I would not worry about unit tests; we're not testing the updater.py file thoroughly anyway. I would like to see an additional job set up in ci/generate_azure_pipelines_matrices.py that would only pass because of the changes in this PR. You would probably have to make changes to steps.yml. I'm willing to help if you need it.

What do you think, @miurahr?

[miurahr]

It is always better to have CI test that cover a code the patch changed, and integration test with actual repository.
We already have many CI tests in azure-pipelines, and increasing cases in version by version.

A CI test server, MS hosted, is provided by azure pipelines free plan.

1 Microsoft-hosted job with 1,800 minutes per month for CI/CD and 1 self-hosted job with unlimited minutes per month.

aqtinstall consumed 336 build minutes in total 360 build minutes in this month in my projects.

We can add more CI job if we can wait the jobs finished.

[ddalcino]

A CI test server, MS hosted, is provided by azure pipelines free plan.

1 Microsoft-hosted job with 1,800 minutes per month for CI/CD and 1 self-hosted job with unlimited minutes per month.

aqtinstall consumed 336 build minutes in total 360 build minutes in this month in my projects.

Maybe it's time to audit the jobs we have and remove anything that's not really high value. I just added 6 new jobs in #648, for a total of 49 Azure builds by my count. I'm sure we can find a few that we don't need anymore.

[miurahr]

FYI: I use https://marketplace.visualstudio.com/items?itemName=ms-devlabs.BuildandTestUsage to check build minutes.

[iakov]

The only thing I can see that this PR is lacking is additional tests. I think it's clear that it's not going to break any existing functionality, but I would like to see proof in CI that this change is fixing something, and a way to prevent regressions in the future.
[...] I would like to see an additional job set up in ci/generate_azure_pipelines_matrices.py that would only pass because of the changes in this PR. You would probably have to make changes to steps.yml. I'm willing to help if you need it.

Ok, I like this idea to reproduce the problem with tests in CI, I hope there is even a chance to reproduce with current build configurations. In my case this happened in 5.11 win64_msvc2017_64 and with 5.11 win32_mingw73
Now as a workaround I do not install qttools module on Windows for CI builds, it helps, so there is no rush for me.

[ddalcino]

I am curious about this value: $$[QT_INSTALL_LIBS]

I've never seen it before, but it looks like it's internal to qmake: https://doc.qt.io/qt-6/qmake-environment-reference.html

Should we be using these built-in variables to patch other values as well? It seems inconsistent to hard-code specific paths in some places, and qmake variables in others. Personally, I like the idea of using qmake variables in more places, as long as it makes sense.

[iakov]

I treat built-in and internal use only terms differently, and propose to use built-ins instead of hard-coded paths. qmake -query shows built-ins, and for cross-platform environment these vars are usually well-defined. Worth noting, that the decision between QT_INSTALL_LIBS vs. QT_HOST_LIBS (and similar variables) should be done each time.
I can see these vars are actively used in installed prf and prl files.
Also, there are /raw, /dev , and sometimes /get properties, which are occasionaly useful. One can find examples in /mkspecs, f.e. $$[QT_INSTALL_LIBS/raw]

[miurahr]

@iakov progress?

[iakov]

@miurahr , sorry, I've forgotten to do this.
I've checked locally with aqtinstall==3.1.10 once again.

1. Install Qt 5.11 with
   aqt install-qt windows desktop 5.11 win64_msvc2017_64 --archives qtwinextras qtmultimedia qtbase qttools -O c:\tmp\testQt123
2. Now C:\tmp\testQt123\5.11.3\msvc2017_64\lib\Qt5UiTools.prl contains incorrect library reference to c:/Users/qt/work/install/lib\\Qt5Widgets.lib
3. To test the build (linker failure) one can use empty test.cpp and dummy test.pro with the following minimalistic text

TARGET=test
QT+=uitools
SOURCES=test.cpp

then qmake to get an incorrect Makefile and nmake to get the error LINK : fatal error LNK1181: cannot open input file 'c:\Users\qt\work\install\lib\Qt5Widgets.lib'

Here are all mentioned files for convenience: test.zip

[iakov]

I would kindly appreciate any ideas about the CI test. Where to inject it? The example from the comment above is enough to test reproducibility, isn't it? To finish the build successfully, the test.cpp, probably, should be not empty, something like

#include <QtUiTools>
int main() { return 0; }

So, I'm ready to improve the PR, but I need an idea of the best place to add the test.

[miurahr]

For unit test which checks a mod function of changes of Qt5UiTools.prl, for example, you can inject the test in
https://github.com/miurahr/aqtinstall/blob/master/tests/test_updater.py

Unit tests will run on GitHub Actions.

For integration test, that run qmake and built test program,
https://github.com/miurahr/aqtinstall/blob/master/ci/steps.yml
is best place.

It will be run on Azure-Pipelines.