Finding Qt with CMake: Missing moc, uic, rcc - windows

I'm trying to fix the installation of a custom built Qt. I'm using the qt.conf from this very similar question. However, CMake 2.8.7 is still unable to find moc, uic, and rcc.
CMake Error at C:/Program Files (x86)/CMake 2.8/share/cmake-2.8/Modules/FindPackageHandleStandardArgs.cmake:97 (MESSAGE):
Could NOT find Qt4 (missing: QT_MOC_EXECUTABLE QT_RCC_EXECUTABLE
QT_UIC_EXECUTABLE) (found suitable exact version "4.8.1")
I have manually set the QT_QMAKE_EXECUTABLE variable to the correct value, namely B:/lib/vs10/Qt-4.8.1-VS10x64/bin/qmake.exe. After deploying the qt.conf file, qmake -v returns the correct path:
c:\>B:/lib/vs10/Qt-4.8.1-VS10x64/bin/qmake.exe -v
QMake version 2.01a
Using Qt version 4.8.1 in B:/lib/vs10/Qt-4.8.1-VS10x64/lib
qmake -query QT_INSTALL_PREFIX also returns the correct path. Note that I can't use environment variables because we need different Qt versions for different projects.
What am I missing?

You should set CMAKE_PREFIX_PATH to B:/lib/vs10/Qt-4.8.1-VS10x64/bin instead of setting QT_QMAKE_EXECUTABLE. It will help cmake to find all qt executables.

The problem was that they decided to make QT_BINARY_DIR a CACHE INTERNAL variable, which wasn't reset properly after changing qt.conf and deleting the QT_* variables in CMake. QT_BINARY_DIR is only reset if the path of the qmake.exe changes. After clearing the cache it worked.
The lessons I draw from this: Don't use CACHE INTERNAL, just FORCE and mark_as_advanced.

Related

Building a cmake project which uses boost with a local distribution

I'm trying to build kenlm which uses boost. The version of boost already installed on the system seems incompatible or too old or broken.
I have successfully built a copy of boost in my ~/local directory. I would like to tell cmake to use the boost headers found under ~/local/include and the libraries in ~/local/lib instead. However I can't see how to tell cmake to look at my custom path for libraries or headers. I've tried setting LD_LIBRARY_PATH to ~/local/lib:$LD_LIBRARY_PATH. Is there an equivalent variable for include path as well? I haven't been able to find one.
If there is no way to do this with just environment flags, I've been trying to edit the CMakeLists.txt file but haven't had much success. I tried editing in my include path but it still uses whatever find_package(Boost ..) finds which is the /usr/include header.

CMake cannot find newer CUDA package?

I have both CUDA versions 7.5 and 8.0 installed but cmake seems to only be able to find the 7.5 version. Running this code:
find_package(CUDA 8.0 REQUIRED)
Gives this error:
CMake Error at P:/Program Files/CMake/share/cmake-3.9/Modules/FindPackageHandleStandardArgs.cmake:137 (message):
Could NOT find CUDA: Found unsuitable version "7.5", but required is at
least "8.0" (found C:/Program Files/NVIDIA GPU Computing Toolkit/CUDA/v7.5)
Even though v8.0 is in the same directory as v7.5. Is this a problem with cmake, or am I doing something wrong here?
No matter how many CUDA toolkits you have installed find_package(CUDA) finds the one that has its nvcc (typically located in <CUDA root dir>/bin) in the environment variable $PATH. If there are several nvcc in $PATH, it will pick up the first one. On windows, installer typically adds relevant environment variables automatically, so the version found depends on the order of installation.
You should not be using find_package(CUDA) anymore as CMake now has first-class support for CUDA.
For details check:
CMake documentation for FindCUDA
First few paragraphs of the header comment in Modules/FindCUDA.cmake
What are PATH and other environment variables, and how can I set or use them?
You could feed CMake with the path to CUDA explicitly, by setting the CUDA_TOOLKIT_ROOT_DIR flag from CMake command line:
cmake -DCUDA_TOOLKIT_ROOT_DIR=<path-to-cuda-8.0>.
CUDA version detection is done by CMake's findCUDA function:
https://cmake.org/cmake/help/v3.0/module/FindCUDA.html
It's possible that for some reason, findCUDA search fails to locate CUDA 8.0 you have installed.
It might be that CUDA_BIN_PATH is set to 7.5, and therefore CMake picks that.

Cannot specify BOOST_ROOT for cmake

I have multiple versions of Boost installed (Windows 7/MinGW). I need to use a particular one (1.53.0).
I defined BOOST_ROOT in the CMakeFiles.txt file: SET(BOOST_ROOT C:/boost_1_53_0/), but I keep getting this error:
> cmake .
BOOST_ROOT=C:/boost_1_53_0/
CMake Error at C:/Program Files (x86)/CMake 2.8/share/cmake-2.8/Modules/FindBoost.cmake:1191 (message):
Unable to find the requested Boost libraries.
Boost version: 1.48.0
Boost include path: C:/Boost/include/boost-1_48
Detected version of Boost is too old. Requested version was 1.53 (or
newer).
The following Boost libraries could not be found:
boost_filesystem
No Boost libraries were found. You may need to set BOOST_LIBRARYDIR to the
directory containing Boost libraries or BOOST_ROOT to the location of
Boost.
I also defined BOOST_ROOT as an environment variable, but with the same result.
Why is cmake still looking for the old version?
Try this:
cmake -DBOOST_ROOT=path
I also struggled with this same problem for a while. If this is the same issue that I had, then the problem is you aren't running the CMake configuration completely fresh without any cache. Once it runs once and finds the default installation (C:\Boost or /usr/include) it will continue to find that one regardless of the value of BOOST_ROOT. So make sure to completely delete any generated build files. Then set BOOST_ROOT to your desired separate installation and it should work fine.
This is also mentioned by jaor on the previously linked question: How can I get cmake to find my alternative boost installation?
If you are using a precompiled version of Boost libraries for Visual Studio, they come in a specific flavor of MSVC version and bitness. I needed to point CMake to that specific location - in my case, setting BOOST_ROOT to C:/local/boost_1_59_0 and BOOST_LIBRARYDIR to C:/local/boost_1_59_0/lib64-msvc-11.0 helped.

Boost 1.50 CMake 2.8 and Ogre 1.8 - win64 - dynamic linking

I've built the dynamic boost libraries required by the Ogre 3d engine (thread and date_time). My boost directory is in C:\boost , the lib is in C:\boost\lib and the include in C:\boost(\boost) as required by the standards.
If you're familiar with CMake and Ogre (since that's the simplest way to build any Ogre repository clone from sources), you know that there isn't much else to specify. That's not true in my case: Cmake always reports that it cannot find boost. And this happens only when I try to build the Ogre 1.8 version from their repository. When I use the Ogre 2.0 experimental unstable (at the time I wrote this question), boost is successfully found and so are its threading and date-time components.
Has anyone got any ideas? Preferably, has anyone tried to build the Ogre 1.8 sources this way?
I did try almost everything (even command line cmake), but with no positive results.
I've asked this question almost twice on the Ogre forums and nothing from those sources solved the problem for the stable release of Ogre.
What is it that makes Cmake derail so much when building one version over the other? How can I at least check for boost's existence in CMake (without creating a build solution or anything else)?
There must be a simple command line flag or a simple script to run with cmake, but apart from the FindBoost.cmake file, nothing else really helps (and that one is too big to make something out of it at a quick glance).
UPDATE
Using sakra's suggestion, I see that boost is recognized:
-- [ C:/Program Files (x86)/CMake 2.8/share/cmake-2.8/Modules/FindBoost.cmake:6
7 ] location of version.hpp: C:/boost/boost/version.hpp
-- [ C:/Program Files (x86)/CMake 2.8/share/cmake-2.8/Modules/FindBoost.cmake:7
6 ] version.hpp reveals boost 1.50.0
but although this section does reveal that boost is where it should be, the thread and date_time libraries are invisible to CMake.
The Boost_USE_STATIC_LIBS flag is set to OFF/FALSE, just in case..
UPDATE using the --find-package cmake command line argument:
C:\Ogre18\Build>cmake --find-package -DNAME=Boost -DCOMPILER_ID=GNU -DLANGUAGE=C
XX -DMODE=EXIST
Boost found.
Ultimately, cmake doesn't find the required components. Can one check for specific libraries belonging to a boost installation?
Try invoking cmake with the variable Boost_DEBUG set to TRUE. This may give you some hints on why the FindBoost module does not find your Boost installation.
cmake -DBoost_DEBUG=TRUE .

Cmake doesn't find Boost

I'm trying to configure a project using CMake, but it fails to find Boost libraries even though they are in the specified folder. I have specified Boost_INCLUDE_DIR, Boost_LIBRARYDIR and BOOST_ROOT , but I still get an error saying that CMake is not able to find Boost. What could be the reason of such error?
Are you sure you are doing it the correct way? The idea is that CMake sets BOOST_INCLUDE_DIR, BOOST_LIBRARYDIR and BOOST_ROOT automatically. Do something like this in CMakeLists.txt:
FIND_PACKAGE(Boost)
IF (Boost_FOUND)
INCLUDE_DIRECTORIES(${Boost_INCLUDE_DIR})
ADD_DEFINITIONS( "-DHAS_BOOST" )
ENDIF()
If boost is not installed in a default location and can, thus, not be found by CMake, you can tell CMake where to look for boost like this:
SET(CMAKE_INCLUDE_PATH ${CMAKE_INCLUDE_PATH} "C:/win32libs/boost")
SET(CMAKE_LIBRARY_PATH ${CMAKE_LIBRARY_PATH} "C:/win32libs/boost/lib")
Of course, those two lines have to be before the FIND_PACKAGE(Boost) in CMakeLists.txt.
There is more help available by reading the FindBoost.cmake file itself. It is located in your 'Modules' directory.
A good start is to set(Boost_DEBUG 1) - this will spit out a good deal of information about where boost is looking, what it's looking for, and may help explain why it can't find it.
It can also help you to figure out if it is picking up on your BOOST_ROOT properly.
FindBoost.cmake also sometimes has problems if the exact version of boost is not listed in the Available Versions variables. You can find more about this by reading FindBoost.cmake.
Lastly, FindBoost.cmake has had some bugs in the past. One thing you might try is to take a newer version of FindBoost.cmake out of the latest version of CMake, and stick it into your project folder alongside CMakeLists.txt - then even if you have an old version of boost, it will use the new version of FindBoost.cmake that is in your project's folder.
Good luck.
For me this error was simply because boost wasn't installed so on ubuntu:
sudo apt install build-essential libboost-system-dev libboost-thread-dev libboost-program-options-dev libboost-test-dev
I struggled with this problem for a while myself. It turned out that cmake was looking for Boost library files using Boost's naming convention, in which the library name is a function of the compiler version used to build it. Our Boost libraries were built using GCC 4.9.1, and that compiler version was in fact present on our system; however, GCC 4.4.7 also happened to be installed. As it happens, cmake's FindBoost.cmake script was auto-detecting the GCC 4.4.7 installation instead of the GCC 4.9.1 one, and thus was looking for Boost library files with "gcc44" in the file names, rather than "gcc49".
The simple fix was to force cmake to assume that GCC 4.9 was present, by setting Boost_COMPILER to "-gcc49" in CMakeLists.txt. With this change, FindBoost.cmake looked for, and found, my Boost library files.
You can also specify the version of Boost that you would like CMake to use by passing -DBOOST_INCLUDEDIR or -DBOOST_ROOT pointing to the location of correct version boost headers
Example:
cmake -DBOOST_ROOT=/opt/latestboost
This will also be useful when multiple boost versions are on the same system.
I also had a similar problem and discovered that the BOOST_INCLUDE_DIR, BOOST_LIBRARYDIR and BOOST_ROOT env variables must hold absolute paths.
HTH!
In my case Boost was not installed. I used below command on Mac and then cmake find_package(Boost) works like a charm
brew install Boost
Please note upper case 'B' in Boost!
If you are building your own boost do not forget to use the --layout=versioned otherwise the search for a particular version of library will fail
For cmake version 3.1.0-rc2 to pick up boost 1.57 specify -D_boost_TEST_VERSIONS=1.57
cmake version 3.1.0-rc2 defaults to boost<=1.56.0 as is seen using -DBoost_DEBUG=ON
cmake -D_boost_TEST_VERSIONS=1.57 -DBoost_DEBUG=ON -DCMAKE_BUILD_TYPE=Debug -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++
One more bit of advice for anyone trying to build CGAL in particular, with statically linked Boost. It is not enough to define Boost_USE_STATIC_LIBS; it gets overridden by the time Boost_DEBUG outputs its value. The thing to do here is to check the "Advanced" checkbox and to enable CGAL_Boost_USE_STATIC_LIBS.
I had the same problem while trying to run make for a project after installing Boost version 1.66.0 on Ubuntu Trusty64. The error message was similar to (not exactly like) this one:
CMake Error at
/usr/local/Cellar/cmake/3.3.2/share/cmake/Modules/FindBoost.cmake:1245 (message):
Unable to find the requested Boost libraries.
Boost version: 0.0.0
Boost include path: /usr/include
Detected version of Boost is too old. Requested version was 1.36 (or newer).
Call Stack (most recent call first):
CMakeLists.txt:10 (FIND_PACKAGE)
Boost was definitely installed, but CMake couldn't detect it. After spending plenty of time tinkering with paths and environmental variables, I eventually ended up checking cmake itself for options and found the following:
--check-system-vars = Find problems with variable usage in system files
So I ran the following in the directory at issue:
sudo cmake --check-system-vars
which returned:
Also check system files when warning about unused and uninitialized variables.
-- Boost version: 1.66.0
-- Found the following Boost libraries:
-- system
-- filesystem
-- thread
-- date_time
-- chrono
-- regex
-- serialization
-- program_options
-- Found Git: /usr/bin/git
-- Configuring done
-- Generating done
-- Build files have been written to: /home/user/myproject
and resolved the issue.
See FindBoost.cmake first. The variables you set are the correct ones but they should be all uppercase.
Make sure the library architecture matches with CMake configuration.
cmake -A x64 ..
I suggest creating a minimal executable which only includes a Boost library to see if it compiles.
#include <iostream>
#include <boost/date_time.hpp>
int main() {
using namespace std;
using namespace boost::gregorian;
date today = day_clock::local_day();
cout << today << endl;
}
find_package(Boost REQUIRED COMPONENTS
date_time
)
include_directories(${Boost_INCLUDE_DIR})
link_directories(${Boost_LIBRARY_DIRS})
add_executable(test_boost "test_boost.cpp")
target_link_libraries(test_boost Boost::date_time)
Start debugging by checking Boost_FOUND first.
message(STATUS "Boost_FOUND: ${Boost_FOUND}")
The version should be found even if no libraries are found. (Boost_VERSION)
If Boost_LIBRARY_DIRS becomes non-empty, it should compile.
I had the same problem, and none of the above solutions worked. Actually, the file include/boost/version.hpp could not be read (by the cmake script launched by jenkins).
I had to manually change the permission of the (boost) library (even though jenkins belongs to the group, but that is another problem linked to jenkins that I could not figure out):
chmod o+wx ${BOOST_ROOT} -R # allow reading/execution on the whole library
#chmod g+wx ${BOOST_ROOT} -R # this did not suffice, strangely, but it is another story I guess
This can also happen if CMAKE_FIND_ROOT_PATH is set as different from BOOST_ROOT.
I faced the same issue that in spite of setting BOOST_ROOT, I was getting the error.
But for cross compiling for ARM I was using Toolchain-android.cmake in which I had (for some reason):
set(BOOST_ROOT "/home/.../boost")
set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} --sysroot=${SYSROOT}")
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} --sysroot=${SYSROOT} -I${SYSROOT}/include/libcxx")
set(CMAKE_CXX_LINK_FLAGS "${CMAKE_CXX_LINK_FLAGS}")
set(CMAKE_FIND_ROOT_PATH "${SYSROOT}")
CMAKE_FIND_ROOT_PATH seems to be overriding BOOST_ROOT which was causing the issue.
For those using python3.7 docker image, this solved:
apt install libboost-system-dev libboost-thread-dev
Maybe
brew install boost
will help you.

Resources