Homebrew-core: qt5: cmake find_package(Qt5Core) doesn't work when linked to /usr/local

[scpeters]

Please follow the general troubleshooting steps first:

• [X] Ran brew update and retried your prior step?
• [X] Ran brew doctor, fixed as many issues as possible and retried your prior step?
• [X] Confirmed this is problem with specific formulae and not Homebrew/brew? If it's a general Homebrew/brew problem please file this issue at https://github.com/Homebrew/brew/issues/new

Bug reports:

I have a 3rd-party package that uses cmake to find qt5 with a find_package(Qt5Core) call. The find_package call works if the CMAKE_PREFIX_PATH is set to /usr/local/opt/qt5 but fails if CMAKE_PREFIX_PATH is set to /usr/local with the following console output:

~~~
cmake ..
-- The C compiler identification is AppleClang 7.0.2.7000181
-- The CXX compiler identification is AppleClang 7.0.2.7000181
-- Check for working C compiler: /usr/local/opt/ccache/libexec/cc
-- Check for working C compiler: /usr/local/opt/ccache/libexec/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /usr/local/opt/ccache/libexec/c++
-- Check for working CXX compiler: /usr/local/opt/ccache/libexec/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
CMake Error at /usr/local/lib/cmake/Qt5Core/Qt5CoreConfig.cmake:15 (message):
The imported target "Qt5::Core" references the file

 "/usr/local/.//mkspecs/macx-clang"

but this file does not exist. Possible reasons include:

• The file was deleted, renamed, or moved to another location.

• An install or uninstall procedure did not complete successfully.

• The installation package was faulty and contained

  "/usr/local/lib/cmake/Qt5Core/Qt5CoreConfigExtras.cmake"

  but not all the files it references.

Call Stack (most recent call first):
/usr/local/lib/cmake/Qt5Core/Qt5CoreConfigExtras.cmake:50 (_qt5_Core_check_file_exists)
/usr/local/lib/cmake/Qt5Core/Qt5CoreConfig.cmake:141 (include)
CMakeLists.txt:2 (find_package)

-- Configuring incomplete, errors occurred!
See also build/CMakeFiles/CMakeOutput.log".
~~~

The following is a sufficient CMakeLists.txt to reproduce the issue:

~
cmake_minimum_required(VERSION 2.8 FATAL_ERROR)
find_package (Qt5Core)
~

I only noticed this recently since qt5 was promoted from keg_only. I investigated the error messages, and noticed that qt5 has a mkspecs folder in its Cellar that is not linked into /usr/local/mkspecs. This causes a problem with the find_package call since it tries to find the mkspecs folder relative to where the cmake config file is found, but that folder isn't in /usr/local/mkspecs.

I expect that we won't be linking the mkspecs folder to /usr/local any time soon. As an alternative, I have a patch for qt5 that forces the cmake config files to use an absolute path to the mkspecs folder:

• https://gist.github.com/scpeters/d8ec8c1bd4c16f03084a696b47ba6383

I don't expect this patch would be accepted upstream, since the problem comes from brew's linking to /usr/local. Should I submit a pull request to add the patch to the qt5 formula?

[MikeMcQuaid]

Great work here.

I don't expect this patch would be accepted upstream, since the problem comes from brew's linking to /usr/local. Should I submit a pull request to add the patch to the qt5 formula?

We should definitely submit this upstream; we don't like having any patches that we haven't at least tried to submit upstream. Could you do that and create a PR linking to the upstream patch submission? @steveire may have thoughts/help here.

[ilovezfs]

I don't expect this patch would be accepted upstream

I don't see why not if it doesn't break anything else.

[ilovezfs]

Same problem again: https://bot.brew.sh/job/Homebrew%20Games%20Pull%20Requests/1201/version=sierra/console

[steveire]

This is https://github.com/Homebrew/legacy-homebrew/issues/29938 btw, and you can hit similar issues with any package which installs cmake config files and references paths which are not part of your symlink system.

The upstream Qt files should keep relative paths, so you will have to do patching on the homebrew side to make them absolute.

[ilovezfs]

The upstream Qt files should keep relative paths

why?

[steveire]

The upstream Qt binary distribution installer asks the user to specify an install location. The installation infrastructure should not have to rewrite those files for example. Relative paths allow avoiding a host of issues like that.

[ilovezfs]

Well that's a bit of a mess, then, because we're not going to want to patch it forever. So permanent keg_only status sounds likely since a top level mkspecs folder just for Qt would be goofy.

[steveire]

The mkspecs folder needs to be specified only for a single header file (qplatformdefs.h). If upstream Qt changes to install that file in include/QtCore or so, then the mkspecs path would not need to be in the cmake config files at all. Perhaps that is a goal for you to work towards with upstream Qt.

[ilovezfs]

Aren't we going to have this same problem with the other Qt-specific folders installed directly into the prefix?

/usr/local/Cellar/qt5/5.7.1/doc: directory
/usr/local/Cellar/qt5/5.7.1/mkspecs: directory
/usr/local/Cellar/qt5/5.7.1/phrasebooks: directory
/usr/local/Cellar/qt5/5.7.1/plugins: directory
/usr/local/Cellar/qt5/5.7.1/qml: directory
/usr/local/Cellar/qt5/5.7.1/translations: directory

[steveire]

Of the rest, the cmake config files additionally look for content in the plugins directory currently too, but it does so by globbing. I suppose that globbing will simply not find the plugins when using homebrew, so some features might not work with homebrew and that might break a cross-platform experience of some users. That's a lesser impact than the mkspecs issue though I think.

I could imagine the files potentially looking for docs and translations some day too if that would help users make their own docs which link to Qt docs, or re-use Qt translations etc. However, no one is working on that. It's something unlikely to happen, but would be accepted upstream if someone contributed it some day.

[ilovezfs]

some features might not work with homebrew and that might break a cross-platform experience of some users

Yeah, that's not good if it was previously working properly when qt5 was keg_only. It sounds like ideally (for us) upstream would have plugins in lib/plugins or share/qt/plugins, or something like that, following FHS.

Immediately, it seems like we have a few choices:
1) patch qt so mkspecs and plugins can be found by absolute path
2) revert to keg_only
3) create new top level directories in /usr/local named mkspecs and plugins (this is problematic because we've been encouraging users to set ownership root:wheel on /usr/local, which means any new top-level folders will require an act of Congress)
4) watch the :boom: play out and do nothing

[MikeMcQuaid]

@steveire Unlike other package managers we like to get our patches upstream rather than keep them around indefinitely. Would it be possible for us to get something upstream that does uses a realpath equivalent on the relative paths to address this issue?

[MikeMcQuaid]

@steveire If that patch should be in CMake itself we could consider that too.

[MikeMcQuaid]

Have opened https://github.com/Homebrew/homebrew-core/issues/8408 as a temporary workaround.

[scpeters]

@steveire thanks for the pointer to https://github.com/Homebrew/legacy-homebrew/issues/29938

I noticed there was a cmake bug filed, but it doesn't look like it has seen any action:

• https://cmake.org/Bug/view.php?id=14974
• https://gitlab.kitware.com/cmake/cmake/issues/14974

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

[ilovezfs]

Closing this since we have an effective workaround in #8408 but we'd look at a PR with a better fix if it's been upstreamed.

[Lekensteyn]

For downstream users: brew install <package-using-qt5> works with CMake because something sets CMAKE_PREFIX_PATH. To make CMake recognize Qt5 outside brew, add this to CMakeLists.txt before any find_package(Qt5...) call:

if(APPLE AND EXISTS /usr/local/opt/qt5)
    # Homebrew installs Qt5 (up to at least 5.9.1) in
    # /usr/local/qt5, ensure it can be found by CMake since
    # it is not in the default /usr/local prefix.
    list(APPEND CMAKE_PREFIX_PATH "/usr/local/opt/qt5")
endif()

[scpeters]

I just submitted a variant of my patch upstream in https://github.com/qt/qtbase/pull/15 and am asking if they can expose a build option that we could invoke from the qt build formula to use absolute paths instead of relative paths. Fingers crossed...