I'm on windows, tried to install EASTL, it got installed in Program Files instead of compiler's path.
Maybe I should change something in CMakeLists?
Library's CMakeLists: https://github.com/electronicarts/EASTL/blob/master/CMakeLists.txt
Commands I used:
cmake -G"MSYS Makefiles"
make
make install
It's a little tricky because MSYS2's CMake is a native Windows program that only understands Windows paths, and MSYS2 has automatic conversions of paths from POSIX-style to Windows-style that gets in the way sometimes.
These commands should work:
MSYS2_ARG_CONV_EXCL=- cmake . -G"MSYS Makefiles" -DCMAKE_INSTALL_PREFIX=$MSYSTEM_PREFIX
make install DESTDIR=/
Related
When I install dependencies using conan install --build=missing conan executes cmake executable to build them if they are missing. But if I have two different versions of cmake installed in the system, cmake and cmake3, what can I do to force conan to use cmake3 binary?
I've figured it out. You can set an environment variable CONAN_CMAKE_PROGRAM to tell conan to use different cmake executable.
https://github.com/conan-io/conan/blob/7387805817aa50ad8545549b66be725f38ddb143/conans/client/build/cmake.py#L52
I have cmake 3.2.3 installed via pacman. I get an error when I try to use it from a msys64 shell:
$ cmake -G "MSYS Makefiles" ..
CMake Error: Could not create named generator MSYS Makefiles
cmake --help does not list it as an available generator.
I do see there is an MSYS.cmake in /usr/share/cmake-3.2.3/Modules/Platform.
What am I missing?
Instead of installing the cmake package, I think you need to install mingw-w64-i686-cmake (or the 64-bit version mingw-w64-x86_64-cmake).
I got the exact same message when trying to run cmake in the MSYS shell. Use a MinGW Shell (for instance MinGW-w64 Win64 Shell) instead.
If you compile native Windows binaries on Linux with MinGW
The MinGW and MSYS generators are only available on Windows based distributions. See #ifdef in cmake.cxx:
#if defined(_WIN32) && !defined(__CYGWIN__)
If you're cross-compiling use one of the available MinGW toolchains. See e.g. "How to use MinGW to cross compile software for Windows" chapter in CMake's wiki.
If you compile Windows binaries on Windows with MinGW
On my Windows PC I only have one CMake installation (the normal MSI Windows Installer with CMake directory added to PATH environment), which works from standard CMD shells and from my MSYS shells.
So in this case there is no need to install a special MinGW version of CMake (like e.g. for CygWin).
But I've rebuild CMake from source with MinGW-w64 several times lately to test some performance optimizations of cmake.exe and it did not work out-of-the-box. To work around the linker errors I've added -DCMAKE_EXE_LINKER_FLAGS="-Wl,--allow-multiple-definition" like recommended here and the resulting cmake.exe still supports the "MSYS Makefiles" generator.
So yes, there is - as you have commented - most probably something wrong with the pacman build.
I guess the pacman build is just broken, so I've resolved this issue by installing the Windows version of CMake from cmake.org with the msi installer.
I am using Point cloud library 1.5.1. When I run CMake 3.4.0-rc2 to build my project, it has error:
Could NOT find PkgConfig (missing: PKG_CONFIG_EXECUTABLE)
How do I fix this error?
This error is raised because the pkg-config utility is not available on your system.
Using PkgConfig with CMake is not a truly cross-platform solution, as Windows does not come with the pkg-config utility installed. (The PCL developers should instead use find_package() in their CMake. Perhaps, this is worth opening up a bug report on their Github.) On Linux, this is an easy fix; you can install pkg-config like this:
sudo apt-get install pkg-config
However, on Windows, the process is more involved. There are several solutions for installing pkg-config on Windows documented here. I'm not sure which most directly applies to your situation, so I suggest reading through some of those. After successfully installing the pkg-config utility on your Windows machine, clear your CMake cache, and re-run CMake. This should remove the error, and allow your build to proceed.
Install vcpkg: https://vcpkg.io/en/getting-started.html
Install pkgconf:
.\vcpkg install pkgconf
If use CMake, delete the Cache files/folders: CMakeCache.txt and CMakeFiles. After that, run the command
cmake .. -DCMAKE_TOOLCHAIN_FILE=C:\dev\vcpkg\scripts\buildsystems\vcpkg.cmake
On Fedora 34, it was because of multiple pkg-config
/home/sapillai/go/bin/pkg-config
/home/sapillai/go/bin/pkg-config
/usr/bin/pkg-config
/home/sapillai/go/bin/pkg-config
I deleted the others and kept /usr/bin/pkg-config. Error was gone.
is there any specific reason why CMake doesn't find windres.exe from MingW as the RC compiler? The MingW dir is in my PATH variable, windres.exe does exist.
I always have to set the CMAKE_RC_COMPILER variable by hand to windres.exe in the cmake GUI.
After googling quite a while now, I only found out that more people have this problem, but I never found any real solution...
I have the latest cmake (2.8.5).
Only thing I found was: http://public.kitware.com/Bug/view.php?id=4068 but the things describes there don't work for me.
One workaround is to edit the CMakeCache.txt
//RC compiler.
CMAKE_RC_COMPILER:FILEPATH=g:/dev/Rtools/MinGW/bin/windres.exe
(or whatever the path to your MinGW install happens to be)
Then run cmake again
For MinGW, use cmake -G "MinGW Makefiles" source-directory/
If you have MSYS installed, use cmake -G "MSYS Makefiles" source-directory/
No plumbing needed.
Many bug fixes have been merged into CMake related to "windres" since the 2.8.5 release.
Try using CMake 2.8.12 or later: it should work with windres "out of the box" at this point.
I want to use kdevelop4 for c++ programming but when I try to run the application kdevelop4 wants cmake binary file! How can I solve this problem?
It sounds like you need to install CMake. If you are on a Linux system, aptitude install cmake (for Debian/ubuntu) or yum install cmake (for Red Hat/Fedora) should do the trick. On Windows, you may need to download and install CMake yourself.