Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
wants to merge 1 commit into from
Closed
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
9 changes: 9 additions & 0 deletions aqt/updater.py
Original file line number Diff line number Diff line change
Expand Up @@ -107,6 +107,11 @@ def _detect_qmake(self) -> bool:
return True
return False

def patch_prl(self, oldvalue):
for prlfile in self.prefix.joinpath("lib").glob("*.prl"):
self.logger.info("Patching {}".format(prlfile))
self._patch_textfile(prlfile, oldvalue, "$$[QT_INSTALL_LIBS]")
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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]


def patch_pkgconfig(self, oldvalue, os_name):
for pcfile in self.prefix.joinpath("lib", "pkgconfig").glob("*.pc"):
self.logger.info("Patching {}".format(pcfile))
Expand Down Expand Up @@ -300,10 +305,14 @@ def update(cls, target: TargetConfig, base_path: Path, installed_desktop_arch_di
if target.os_name == "linux":
updater.patch_pkgconfig("/home/qt/work/install", target.os_name)
updater.patch_libtool("/home/qt/work/install/lib", target.os_name)
updater.patch_prl("/home/qt/work/install/lib")
elif target.os_name == "mac":
updater.patch_pkgconfig("/Users/qt/work/install", target.os_name)
updater.patch_libtool("/Users/qt/work/install/lib", target.os_name)
updater.patch_prl("/Users/qt/work/install/lib")
elif target.os_name == "windows":
updater.patch_pkgconfig("c:/Users/qt/work/install", target.os_name)
updater.patch_prl("c:/Users/qt/work/install/lib")
updater.make_qtenv2(base_dir, version_dir, arch_dir)
if version < Version("5.14.0"):
updater.patch_qtcore(target)
Expand Down