Page MenuHomePhabricator

Support Qt5_DIR in MITK superbuild
Closed, ResolvedPublic

Description

When Qt 5 is not found CMake suggests to either add an appropriate path to CMAKE_PREFIX_PATH, or to set the Qt5_DIR cache variable. Currently we only support the former variant. However, the past weeks revealed that almost all (internal) MITK users were puzzled as they only tried the non-working latter variant. Hence, we clearly need to support Qt5_DIR as well.

To keep changes to our build system as minimal as possible we should just derive a path from Qt5_DIR (only if set) which we append to CMAKE_PREFIX_PATH (only if not already a list item).

Event Timeline

User kislinsk has pushed new remote branch:

bug-18892-Qt5DIR

[2c8982]: Merge branch 'bug-18892-Qt5DIR'

Merged commits:

2015-03-25 07:55:50 Stefan Kislinskiy [f912d1]
Added support for Qt5_DIR.

In our weekly MITK meeting yesterday we agreed on removing the Qt5_DIR variable completely and relying on the officially documented way how to tell CMake to find Qt5.

The Qt5_DIR is not from us, it is injected by CMake if Qt 5 wasn't found. According to the error output and the Qt documentation it is as official as CMAKE_PREFIX_PATH, despite the note that CMAKE_PREFIX_PATH would be "easier". :)

So for the sake of clarity and from what we have learned from the past weeks, I disagree in "removing" this variable. Even making this variable advanced is not a true option in my opinion. Last but not least, as we cannot (and should not even it would be possible) modify the CMake error output in which Qt5_DIR is one of the two possible valid options, we should behave consistently.

And the best: It's a seven-liner including endifs() right in the Qt 5 handling part in CMakeLists.txt. ;) Usability for free if you ask me. :)

Okay, the descision was based on the (wrong) fact that Qt5_DIR is added by our CMake scripts, but it comes from the find_package(Qt5 ...) calls. I agree with your conclusion then.