find_package does not find existing package

Hi,

I wanted to migrate to cmake and I was very happy following successful the
tutorial.

But now with my project I’m in trouble.

I wanted to manually write cmake files and not use generated stuff from
qtcreator.

I have several qt toolkits installed and I’m not able to select the desired
toolkit with cmake. I started with settings CMAKE_PREFIX_PATH but nothing
changed.
I have to say, that I have CMakeLists.txt opened in editor and parallel a
running cmake-gui, where I delete cache and then press “Configure” …

Next try was to setup a _DIR variable for every used package like this:

set(Qt5_DIR        "/opt/qt5.15/5.15.12/gcc_64/lib/cmake/Qt5" CACHE PATH "Qt5 Root directory")
set(Qt5Core_DIR    "/opt/qt5.15/5.15.12/gcc_64/lib/cmake/Qt5Core" CACHE PATH "Qt5 Core directory")
set(Qt5Widgets_DIR "/opt/qt5.15/5.15.12/gcc_64/lib/cmake/Qt5Widgets" CACHE PATH "Qt5 Widgets directory")
set(Qt5UiTools_DIR "/opt/qt5.15/5.15.12/gcc_64/lib/cmake/Qt5UiTools" CACHE PATH "Qt5 UiTools directory")
set(Qt5Sql_DIR     "/opt/qt5.15/5.15.12/gcc_64/lib/cmake/Qt5Sql" CACHE PATH "Qt5 Sql directory")
set(Qt5Xml_DIR     "/opt/qt5.15/5.15.12/gcc_64/lib/cmake/Qt5Xml" CACHE PATH "Qt5 Xml directory")

followed by the obvious:

find_package(Qt5Core    REQUIRED CONFIG)
find_package(Qt5Widgets REQUIRED CONFIG)
find_package(Qt5UiTools REQUIRED CONFIG)
find_package(Qt5Sql     REQUIRED CONFIG)
find_package(Qt5Xml     REQUIRED CONFIG)

I verified the filesystem, that every searched file is at coded location.
I don’t know why, but package Qt5Sql and Qt5Xml are found, the rest is taken
from /usr/lib …

What am I missing / doing wrong?

I would recommend, for Qt5, to do find_package(Qt5 COMPONENTS) to find its parts. I believe the core package tries really hard to find things from a single installation prefix.

Thank you for your reply!

That was my first try and it did not find a single component.
Then I tried to use cmake like qtcreator does:
setting CMAKE_PROJECT_INCLUDE_BEFORE - which resulted in a crash of cmake-gui.

So for me it looks like I can’t use Qt without qtcreator.
Really bad news :frowning:

Have to rethink my project layout for that.

That’s strange. Does cmake --debug-find give any useful information?

Hi Ben,

Thank you for that extremely valuable tip!
Helped me a lot to understand the process a bit better - even if I was not
able to come to a successful conclusion.

I have these locations of cmake executable on my sytem:

/usr/bin/cmake
/usr/local/bin/cmake (softlink to cmake at /opt/qt5.15...)
/opt/qt6.2/Tools/CMake/bin/cmake
/opt/qt5.15/Tools/CMake/bin/cmake
/opt/qt5.12/Tools/CMake/bin/cmake

According to output of “which cmake” /usr/local is the winner, which means
/opt/qt5.15 (the toolkit I actually use with that project).

When I run cmake --debug-find without any path or dir settings in
CMakeLists.txt, I get this output:

  find_program considered the following locations:

    /home/common/bin/uname
    /home/myself/.local/bin/uname
    /usr/local/bin/uname

  The item was found at

    /usr/bin/uname

That already shows, that cmake does not evaluate the path in the same order as OS.

Next I added a prefix setting for the cmake I use:

set(CMAKE_PREFIX_PATH "/opt/qt5.15/Tools/CMake/bin" CACHE PATH "path of cmake executable")

which leads to this output:

  find_program considered the following locations:

    /opt/qt5.15/Tools/CMake/bin/bin/uname
    /opt/qt5.15/Tools/CMake/bin/sbin/uname
    /opt/qt5.15/Tools/CMake/bin/uname
    /home/common/bin/uname
    /home/myself/.local/bin/uname
    /usr/local/bin/uname

  The item was found at

    /usr/bin/uname

Very very frustrating. The third path should result in a hit, but cmake “finds”
an executable at a location it had not searched for :frowning:

That smells like hardcoded path and debug output is just cheating …

I guess, that’s the key point. If cmake does not find the right location for
itself - I suppose anything else will fail too.

Take the /bin off of the prefix path entry. That variable is a list of installation prefixes to search, not PATH entries. You can see this in the bin/bin/uname search attempt.

Hi,

In the meantime, I am convinced that it makes no difference. Nothing is found
anyway, or just not the right thing :frowning:

I tested some more and it looks like it doesn’t matter at all which variable I
set. It is ignored anyway.

Prompted by the debug messages I tried to set QT_DIR in the environment - and
oh wonder, this was respected. But only for a single value, which
unfortunately had no effect on the packages. So I would have to find the path
for each package and write it into the environment.
I was expecting to save some effort with cmake, but this looks more like the
opposite to me.

Therefore I have to let it be. Even though I liked cmake very much
spontaneously. To me it looks like Qt is not interested in supporting cmake
usage without QtCreator.

What a crap!

I’ve never used QtCreator and CMake works just fine at finding Qt. Something is up with your environment. Do you have more debugging output to share with complete setup information? It’s not really clear what CMake is trying that isn’t working with what you’ve provided.

Hi,

the bigger my project gets, the more i get annoyed with qmake - it’s just an
inadequate tool. In the hope that cmake can do more, I would like to give it
another try.

When translating the current opencascade framework, I noticed that they
managed to do it with Qt.
I then did some research and there is a separate script for Qt included, which
obviously finds all components of Qt in the right place.
I then included that script in my CMakeLists.txt, but there it doesn’t even
come close to working.
The debug output shows that it does find the correct config file, but then claims
that my system doesn’t support shared libs, so it switches to static
libraries.

That is of course complete bullshit!

I work under linux and also build for linux, so of course shared libs are used
there.

Are there some hidden rules that make cmake-files get executed without having
them included?
Or how can I find out, why one CMakeLists.txt works and the other not?

You tip with --debug-find was very helpful. But I stil have no idea, how to
change behaviour

Something sounds very off with your environment. Do you have instructions on how it could be reproduced elsewhere for more detailed investigations? For example, a Dockerfile which makes the desired environment.

Hi Ben,

thank you very much for your attention again!

Something sounds very off with your environment. Do you have instructions on
how it could be reproduced elsewhere for more detailed investigations?

I don’t think, that I have a special environment.

I use debian stable with KDE-desktop (which uses qt internally) and nvidia
environment.
Foreign source packages are installed at /usr/local/src, but I don’t install
most of them. The only installed packages (self compiled and installed) are
conky and opencascade.

Qt-frameworks are installed by Qt-binary installer and all framework releases
are installed somewhere at /opt/…

Each Qt-framework ships its own cmake, but I don’t use it. I use cmake from
debian stable, which is actually of release 3.18.4

Actually I’m using qmake, but it looks like qmake can not handle the
dependencies of my subdirs project. Therefore I wanted to give cmake a try.
Qt converter script (qmake → cmake) does not work on my system, as it was
written for an older python release and I don’t want to install more python
stuff …

I guess I can’t migrate without help.

The environment that CMake GUI sees might not be the same as the one you see at a Unix shell prompt. It depends how you started CMake GUI. The same comment applies to Qt Creator too, although it does at least allow you to see and customise the environment in each kit.

Delete the CMakeCache.txt file in your build directory, and then run CMake again with CMAKE_PREFIX_PATH set to /opt/qt5.15. You should not need to set any ..._DIR variables. If you have a properly installed Qt in that directory, setting CMAKE_PREFIX_PATH alone should result in the following call finding Qt successfully:

find_package(Qt5 REQUIRED COMPONENTS Gui Widgets Core)

If that fails, then show us the directory structure under /opt/qt5.15. In particular, there should be a lib/cmake directory, or something similar to that.

Don’t bother setting CMAKE_PROJECT_INCLUDE_BEFORE to anything. Qt Creator does various things for its own internal purposes or to support workflows that are probably not of interest to you right now. When you’re running CMake directly and just want to get the project configured, you don’t need much more than just CMAKE_PREFIX_PATH.

You can definitely use Qt without Qt Creator. CI jobs run headless and manage to configure and build Qt projects just fine. We just need to work out what’s happening with your environment and perhaps something you’re setting incorrectly.

I’d also recommend you attach the full output from running CMake if things fail with the above steps. That will allow us to see all the potentially relevant details rather than just the bits you identify.

Thank you very much for your intervention.

The environment that CMake GUI sees might not be the same as the one you see
at a Unix shell prompt. It depends how you started CMake GUI.

Well, usually I start both from unix shell prompt. CMake-gui is handy as I can
see the find_package result and it allows to delete cache. So it really helps
investigate changes in CMakeFiles.txt

Your advices looked a bit different so I gave it a try - and it worked right
out of the box. Impressive!

Then I wanted to replay the failures from last try - and it wasn’t possible at
all. Don’t understand it. Today everything works as expected. This includes
every failed statement I tried lately.
I did not change anything related Qt on my machines setup or changed anything
in my development environment. Very strange!
Luckily I saved the log from failure session, so I could send it to you.

Today find_package finds the right toolkit, but entries in cmake-gui are stil
red painted and when I run make, it fails at first file, that it could not find
include-file for QObject.

So may be, I’m a bit further, but it does not feel so.

I append the logfiles. They are complete except for (unused) home dir removed.

cmake.debug (37.6 KB)

cmake_fail.debug (38 KB)