No current clue about qmake, just wondering from my little knowledge:
how does having $$[QT_SYSROOT] here influence any QMAKEPATH env var set? Would pri files installed into a custom prefix still be found?

The SYSROOT variable should not (directly) impact that. The install directory is configured by ECM_MKSPECS_INSTALL_DIR, which usually will point to /usr/lib/mkspecs/modules/ on Linux. For a cross-compile toolchain it will however be additionally prefixed with separate path. But Qt and qmake will also be configured with that prefix so those know to lookup the mkspecs dir under that prefix. Issuing QT += <module> can then trigger the including of the include and lib paths from the .pri generated by this code. So the case I am trying to fix with this patch is the case where the .pri is found (so ECM_MKSPECS_INSTALL_DIR was specified correctly) but now the libs and include paths are pointing to /usr/{include,lib} and not to <cross-compile-prefix>/usr/{include,lib}. Now since <cross-compile-prefix> can differ depending on the installation dir of the tool chain it may not be possible to know that path during compile / install time. However, we can assume that Qt / qmake will know about the sysroot (which is the prefix essentially). So as long qmake is configured for the cross compile our Qt module now should be too.

Thanks for the explanation, fear though I am missing some details and thus have not yet understood the problem and the solution. Not having done much cross-compilation-library-setups naively I would have thought that when building a library which uses ECMGeneratePriFile and preparing it for cross-compilation, the installation prefix would be hardcoded into the generated artifacts.. Seems that instead files are relocated sometimes, changing their path & prefix, or tools snipping of some things? So $$[QT_SYSROOT] would make up for that, when having a library build normally for a system, but then deployed to the cross-compilation system below some path? Just curious in case you have time to teach me, positioning myself here as curious person at the sideline :)

For what I tested at least, the setups I was interested in with my question, non-systemwide installations, like for a developer having their development env in their home folder and helping qmake to find pri files using QMAKEPATH env var, this patch seems to not affect this, so no objections from me :)

To help getting some people who can judge this is a proper patch for the actual purpose, adding some more explicit reviewers now.

Not having done much cross-compilation-library-setups naively I would have thought that when building a library which uses ECMGeneratePriFile and preparing it for cross-compilation, the installation prefix would be hardcoded into the generated artifacts.. Seems that instead files are relocated sometimes, changing their path & prefix, or tools snipping of some things?

There does not seem to be THE way to do it, gcc and alike have --sysroot for overriding the otherwise default of /usr/{include,lib}, cmake has variables which you can change to modify the path from which stuff is loaded, Qt itself uses variables like $$QT_MODULE_INCLUDE_BASE which is filled by MODULE_BASE_INDIR which is filled by resolving a relative filename in the Qt install dir. I thought about using QT_MODULE_INCLUDE_BASE (and the lib alternative) first, but these are no public Qt API and could change any time. In contrast QT_SYSROOT is documented and should do the job I think.

Hi @ablu,

Could you test if my patch in D29274 solves your problem? By making these lines relative to the location of the .pri file, it should work very well in a sysroot context as well.

Hi @dfaure. It looks pretty much the same and I think it should work for us. I will kick off a build to confirm.

looks good! yours is probably a bit more "CMakeish"! So feel free to continue with that one and close this.

Thanks for the quick test!

I'll indeed proceed with the other one, which is more generic (our use case isn't related to QT_SYSROOT).

Actually: can you add your comment (that it works for you) in the other review request, so people know it's been tested by more than me, and discard this one?

Sure!

Though... How does it come that you do not have SYSROOT set in your case? Won't that break in other cases?

I'm using conan, not doing cross compilation.

But with relative paths it's no problem, both use cases work.

Ah, right. If you are using a normal sysroot for system libs, but conan for some libs then it makes sense!