Setting QT_HOST_PATH is required for native build of qt6-main downstream projecs on osx-arm64 #273
Comments
That is exactly the case, see https://github.com/qt/qtbase/blob/53e44e753b7cfc5c873ef5a1fc577cfb6308d9d0/cmake/QtPublicDependencyHelpers.cmake#L236-L241 : Indeed, it seems that the |
|
I think that the fix boils down to pass |
Is this fix to be done at the qt-main level? I think jschuler is better at this stuff than me. i would wait for their response. |
From what I understand yes.
Ok, thanks! I mentioned you by checking just the latest PRs merged |
|
if its a 1 liner, you might as well make the PR. Qt6 builds on the CIs so its pretty easy.... |
|
Great, done: #274 . |
|
actually on conda-forge the osx-arm64 target is cross-compiled from osx-64 platform, so imho nothing wrong here |
Yes, but why there should be a difference in consuming a cross-compiled library as opposed to consume a native build library as part of a native build of a downstream package? In a nutshell, why should |
|
now what happens if we omit QT_HOST_PATH when building a package that depends on qt6 on conda-forge forge for osx-arm64 (which is still cross-compiling) ? |
|
Ok, let me try to recap a bit here, I think there are two main use cases (UC)
If I understood your concern, you want to make sure that in UC2 we still get the nice If I got this correctly, I think the main problem is the logic used in qt to understand if a given build is done using cross-compilation: they actually use "qt6 has been build via cross-compilation" as a proxy for "any library that is using qt6 is being build via cross-compilation", that is clearly wrong in general in the conda context. Would it be ok for you to change the logic to detect if a project is being cross-compiled in some other way? For example by checking the |
|
ok, lets merge #274 |
Great, thanks! |
|
My bad, in #273 (comment) I actually I had a big confusion between two different variables :
|
instead of QT_REQUIRE_HOST_PATH_CHECK QT_NO_REQUIRE_HOST_PATH_CHECK is the variable that we need to set in qt build system, see conda-forge#273 (comment) for details
|
I think I underestimated the situation (one thing that make is complex is that the same code CMake code runs for qt build itself and for downstream build of projects that build against qt). At the moment I do not have a lot of time to look into this, so I propose:
|
@conda-forge/qt-main if you agree feel free to re-open the issue (I do not have the required permissions) |
Solution to issue cannot be found in the documentation.
Issue
It seems that
find_package(Qt6 REQUIRED)fails onosx-arm64(even on native builds) with the error:This was just triggered by the following CMakeLists.txt
or you can easily trigger this by the
cmake-package-checkscript with:See https://github.com/traversaro/debug-find-package-qt6-conda-failure-apple-silicon/actions/runs/9649808633/job/26614067008 for a simple reproducer (and a check that this works fine in
osx-64).It seems that somehow Qt6 wants you to manually set
QT_HOST_PATHif Qt6 was cross-compiled, but I am not sure the rationale of this. Probably the hidden assumption is that they assume that a cross-compiled Qt6 will be consumed in cross-compilation builds?Indeed, I saw that error a lot in conda-forge CI cross-compiled builds, and it was nice, but for regular native builds this is quite unexpected (and it happens also when Qt6 is included only transitively, I originally got it in a project that was doing
find_package(PCL)).Installed packages
Environment info
The text was updated successfully, but these errors were encountered: