I'm interested in CMake, so decided to learn about it. I followed the CMake Tutorial until the point where it states "That is all there is to it. At this point you should be able to build the tutorial", so I thought, let's try it!
Alas, it seems it wasn't all so simple. I initially attempted to run cmake -A "Unix Makefiles" after consulting cmake --help, but no luck there either. Rather, it gives me the following:
CMake Error at CMakeLists.txt:2 (project):
Generator
Unix Makefiles
does not support platform specification, but platform
Unix Makefiles
was specified.
CMake Error: CMAKE_C_COMPILER not set, after EnableLanguage
CMake Error: CMAKE_CXX_COMPILER not set, after EnableLanguage
I began searching around on the Internet and found this, but it gave me the exact same error. Other answers I found seemed to be Windows-related, but myself I'm on Fedora 29.
I want to generate a makefile using CMake, any suggestions? (I have gcc and g++ installed, by the way)
On Fedora, generating Unix Makefiles (e.g. Makefile, which GNU Make will be able to use) is probably the default. In general, don't specify a generator: then you'll get what makes the most sense on your installed OS. Some OS do pick a different default: FreeBSD uses Ninja, for instance.
When running CMake you may need to specify the source-directory. If CMake has been run before, successfully, you can leave off the directory. When there are no other options or arguments to CMake, you'll need to give the directory.
If you've copy-pasted the CMakeLists and C++ files from the tutorial page, this will create whatever build-system comes from the default generator:
cmake .
Do note that if you don't give CMake any arguments at all, then it gives you a usage string. That's why there's that . there, to build from the current directory. If you want to specify a particular generator,
cmake -G "Unix Makefiles" .
If you are building in a separate directory (generally a good idea)
cmake /path/to/the/sources
Your original error message, by the way, tells you that CMake is, by default, using the generator Unix Makefiles, which doesn't support setting a platform. The no-arguments-at-all behavior seems to have tripped you up afterwards.
After a discussion in the comments, I realised the issue was that I had done it wrong from the start. The solution ultimately was to remove all CMake-related files (except for CMakeLists.txt and do it all over again, this time running cmake .. on its own (without any arguments) from a subdirectory.
Related
I'm using CLion with MinGW-GCC on the Windows-x64 platform - This is the background of the problem.
I was trying to install gtest before. But a lot of confusion arose in the middle.
First time I ran those commands(in googletest-release-1.12.1\) according to the instructions of googletest-release-1.12.1\googletest\README.md:
mkdir build
cd build
cmake ..
But I got error messages like:
CMake Error at CMakeLists.txt:51 (project):
Failed to run MSBuild command:
C:/Windows/Microsoft.NET/Framework/v4.0.30319/MSBuild.exe
to get the value of VCTargetsPath:
Then I changed my last command to
cmake -G "MinGW Makefiles" ..
because I use make provided by MinGW. I don't know whether it's right but, it ran properly.
then I called
make
make install
make ran smoothly. But when I ran make install, I got these messages:
Install the project...
-- Install configuration: ""
-- Installing: C:/Program Files (x86)/googletest-distribution/include
CMake Error at googlemock/cmake_install.cmake:41 (file):
file INSTALL cannot make directory "C:/Program Files
(x86)/googletest-distribution/include": No such file or directory.
Call Stack (most recent call first):
cmake_install.cmake:42 (include)
make: *** [Makefile:109: install] Error 1
I have no idea at all this time. So I changed my way. According to this answer, I copied the whole library into my project and edited CMakeLists.txt like this:
cmake_minimum_required(VERSION 3.23)
project(gtest_study)
set(CMAKE_CXX_STANDARD 20)
add_subdirectory(googletest-release-1.12.1)
include_directories(googletest-release-1.12.1/googletest/include)
include_directories(googletest-release-1.12.1/googlemock/include)
add_executable(gtest_study main.cpp)
target_link_libraries(gtest_study gtest gtest_main)
target_link_libraries(gtest_study gmock gmock_main)
So my questions are:
Is there any difference between the two which build it using make and cmake metioned firstly, and just use commands like include_directories and target_link_libraries in CMakeLists.txt? (maybe like .h and .dll file? Or just completely the same? I don't know)
When I use make install to install a library on Windows, what should I do in particular? Specify some directory (I don't know which one) or what?
Although in my system environment I use MinGW-makefile, in CLion which the libraries are eventually used, I use ninja as the generator for CMake (it just comes with CLion, not installed for the system). Do I have to specify it and how? （-G "Ninja"doesn't work in my native env）
The difference between
cmake ..
and
cmake -G "MinGW Makefiles" ..
Is the choice of generator: The former uses the default generator, the latter uses the generator you specified. (cmake --help should put a * next to the default generator.)
Based on the error message I assume this is a visual studio generator and you may not be able to run that one properly from within a MinGW terminal.
In the latter case the default install directory seems to be based on the target OS (Windows) but does not seem to incorporate the fact that you're running from a MinGW terminal where the default install path (C:/Program Files (x86)/googletest-distribution) is not valid.
You could try to fix this by providing it during cmake configuration (passing -D 'CMAKE_INSTALL_PREFIX=/c/Program Files (x86)/googletest-distribution' before the source dir) or by providing the install directory during the installation.
The following process should allow you to install the lib. I'm using my preferred way of building here, i.e. not using build system dependent commands, but using cmake to run the build/install commands. I assume the working directory to be the root directory of the gtest sources:
cmake -G "MinGW Makefiles" -S . -B build
cmake --build build
cmake --install build --prefix '/c/Program Files (x86)/googletest-distribution'
The last command needs to be run with admin privileges, the first 2 I don't recommend running as admin. You could instead install to a directory where you do have the permissions to create directories even without admin privileges.
The difference between using the process described above and using add_subdirectory is that the former results in a installation on the system which can be used via find_package and the google test libs won't be rebuilt for every project where you do this.
...
project(gtest_study)
...
# you may need to pass the install location via -D CMAKE_PREFIX_PATH=<install_location> during configuration for this to work
find_package(GTest REQUIRED)
target_link_libraries(gtest_study PRIVATE GTest::gtest_main GTest::gmock)
The latter builds the google test project as part of your own project build and for every project where you use this approach a seperate version of the google test libs is built. Note: there should be no need to specify the include dirs yourself, since this kind of information is attached to the cmake target and gets applied to the linking target automatically:
#include_directories(googletest-release-1.12.1/googletest/include)
#include_directories(googletest-release-1.12.1/googlemock/include)
add_executable(gtest_study main.cpp)
target_link_libraries(gtest_study PRIVATE gtest_main gmock)
As for 3.: The CMake generator used for building GTest should be independent of the generator of the project using it. The thing that's important is that the compilers used by the build systems are compatible. I cannot go into detail about this, since I've never used CLion and therefore have too little knowlege about the compilers used by it. (Personally I'm working with Visual Studio on Windows.)
I am very new (my first time) to installing software through command lines and source files and C++. So the solution could be quite simple but I just simply don't understand it.
My objective here is to install the GODDeSS-Package following these instructions.
I am currently under the section "How to install the example simulation" and I am stuck on the final step (step 8). To my knowledge, I believe I have installed all the prerequisite software correctly listed from steps 1-3.
Following the procedures when I arrive at step 8, I execute the following command and receive this error:
$cmake C:/Users/Patrick/Desktop/Research/GODDeSS-Package/goddess-package/GODDeSS_4_3/source
...
Could NOT find Boost (missing: regex) (found version "1.59.0")
...
I used the ellipse to show there is text before and after that error message. However this is not the main problem. I was able to over come this with a add-on argument (which I don't really understand how it works) -DBoost_USE_STATIC_LIBS=ON
So after this modification, I get the following results:
$cmake C:/Users/Patrick/Desktop/Research/GODDeSS-Package/goddess-package/GODDeSS_4_3/source -DBoost_USE_STATIC_LIBS=ON
...
-- Generating done
-- Build files have been written to: C:/Users/Patrick/Desktop/Research/GODDeSS-Package/goddess-build
So I assume part 1 of step 8 done correctly? ...since it says "Generating done".
Now here is where I run into the problem. the next command is:
$make -j install
But I don't have a Makefile in the generated files!
Here is a picture of my build directory which I have generated the files into:
Build Directory Picture
I have done some reading and it seems like cmake is Building for Visual Studios 16 2019 so it creates the .sln files instead (theres alot of them! Almost one in every folder). I'm not entire sure how to deal with this situation. Instead I tried to force cmake to generate me a Makefile by using the add-on command -G "MinGW Makefiles" I picked MinGW randomly just because it was one of the few options that generated a Makefile.
So I created a fresh build directory and used the following command:
cmake -G "MinGW Makefiles" C:/Users/Patrick/Desktop/James_L_Pinfold_Research/GODDeSS-Package/goddess-package/GODDeSS_4_3/source -DBoost_USE_STATIC_LIBS=ON
But I get the following error:
CMake Error: CMake was unable to find a build program corresponding to "MinGW Makefiles". CMAKE_MAKE_PROGRAM is not set. You probably need to select a different build tool.
CMake Error: CMake was unable to find a build program corresponding to "MinGW Makefiles". CMAKE_MAKE_PROGRAM is not set. You probably need to select a different build tool.
CMake Error: CMAKE_C_COMPILER not set, after EnableLanguage
CMake Error: CMAKE_CXX_COMPILER not set, after EnableLanguage
-- Configuring incomplete, errors occurred!
So now I'm stuck... I see 2 paths I can go down. 1. Make use of the .sln files created by cmake to install the package... or 2. Somehow make cmake create a Makefile so I can use the make command. Neither of which how to do.
I'm having a hard time trying to find documentations of how to install this package but I have yet to succeed. What can I try next?
I am using Windows 10, Terminal: Git Bash, Visual Studios 2019, Boost_1_5_9, zlib1211, geant4_10_02_p03, and cmake-3.17.2
I want to build my C++ applications from the Windows PowerShell command line using CMake and MinGW.
When I do this in the "normal way," with these commands:
mkdir build
cd build
cmake ..
make
CMake chooses Visual Studio as the default compiler, and doesn't generate any Makefiles for me.
I want CMake to use MinGW as the default compiler, and generate Makefiles.
It works exactly the way that I want it to when I run these commands, adding the -G "MinGW Makefiles" flag:
mkdir build
cd build
cmake .. -G "MinGW Makefiles"
make
How can I make CMake behave this way all the time, without adding the -G "MinGW Makefiles" flag?
I've tried setting up a CMAKE_GENERATOR environment variable in Windows, and pointing it to "path\to\mingw\bin", "path\to\mingw\bin\mingw32-make.exe", as well as a string that reads "MinGW Makefile".
None of these worked for me after running refreshenv and then trying to run cmake .. again.
Does anybody know if this is the correct environment variable to use in order to specify CMake's default behavior? If it is, what value should I be using?
How can I make CMake behave this way all the time, without adding the -G "MinGW Makefiles" flag?
You can't, not in any version of CMake released to date. CMake chooses a generator before it starts evaluating any CMakeLists.txt files. By default, it chooses a generator based on runtime platform and available toolsets, and command-line options are the only way presently available to influence or override CMake's choice of generator.
In comments, #Tsyvarev pointed out an open CMake issue report asking for the very same feature you are asking for. The associated comment thread provides more detail, and the last comment was earlier this year. I would guess that eventually CMake will add support for specifying a generator via environment variable, but for now, your -G option is the only available alternative. You could consider scripting it if you want to save keystrokes and reduce the risk of typos.
I know this is late. but in case someone came here and find this answer useful
all you have to do is to create a function something like this:
function gcmake {cmake .. -G "MinGW Makefiles"}
then you can simply type
mkdir build
cd build
gcmake ..
make
tip: you can add this function to your profile so that it will be saved to any new session. you can follow this nice guide
cmake uses Visual Studio generator for MinGW on Windows by default (even without Visual Studio!), this is the real annoying issue (Cygwin is not affected).
We need to work around MinGW only. What will be the most reliable hook for MinGW? I think MSYSTEM is very popular environment variable that will always be defined for MinGW.
You can place PreLoad.cmake in the project root with the following content:
if (NOT "$ENV{MSYSTEM}" STREQUAL "" AND "$ENV{VisualStudioVersion}" STREQUAL "")
find_program (CMAKE_NINJA_BINARY NAMES "ninja")
if (CMAKE_NINJA_BINARY)
set (
CMAKE_GENERATOR "Ninja"
CACHE INTERNAL "Cmake generator"
)
return ()
endif ()
find_program (CMAKE_MAKE_BINARY NAMES "gmake" "make")
if (CMAKE_MAKE_BINARY)
set (
CMAKE_GENERATOR "Unix Makefiles"
CACHE INTERNAL "Cmake generator"
)
return ()
endif ()
endif ()
Unfortunately this solution is not universal:
MSYSTEM=MINGW64 cmake -G "Unix Makefiles" ..
CMake Error: Error: generator : Unix Makefiles
Does not match the generator used previously: Ninja
Either remove the CMakeCache.txt file and CMakeFiles directory or choose a different binary directory.
If you are setting CMAKE_GENERATOR inside PreLoad.cmake than you are loosing ability to use -G cmake option. If you don't need this option, than this solution will be just fine.
PS It is not possible to access -G option value inside PreLoad.cmake as CMAKE_GENERATOR or another option. So it is not possible to add guard case like NOT DEFINED CMAKE_GENERATOR to check whether generator has been provided explicitly using -G option.
I am attempting to import a manually-created cmake project that I had been using in a different IDE into Netbeans 8.0.2 on Windows 7. Needless to say, my cmake configuration worked fine there.
Netbeans seems to import the directory fine. I imported it in "automatic" (cmake) mode. However, when I attempt to build the project, I get a rather cryptic (Java?) error message:
Makefile:76: recipe for target 'all' failed
process_begin: CreateProcess(NULL, /C/MinGW/bin/make.exe -f CMakeFiles/Makefile2 all, ...) failed.
make (e=2): The system cannot find the file specified.
Knowing very little about Java, I am not sure how to interpret this error. The first directory (/C/MinGW/bin/make.exe) stands out to me as not being in Windows-format, but I am not sure if that's incorrect. I do indeed have a file by that name, as I copied the longer-named mingw make binary so I would only need to type "make".
Presuming this is being run in the project root, and that the first directory is formatted correctly, I don't see any problem with finding these files.
My CMakeLists.txt is:
cmake_minimum_required(VERSION 2.8.4)
set(Project_Name "Test")
set(Test_VERSION_MAJOR 1)
set(Test_VERSION_MINOR 0)
project(${Project_Name})
include_directories(
"${CMAKE_CURRENT_SOURCE_DIR}/inc"
"${CMAKE_CURRENT_SOURCE_DIR}/inc/SDL"
"C:/Users/Bakaiya/Documents/ogre/OgreMain/include"
)
file(GLOB SOURCE_FILES "${CMAKE_CURRENT_SOURCE_DIR}/src/*.cpp")
link_directories(${CMAKE_CURRENT_SOURCE_DIR} ${OPENGL_LIBRARIES})
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++11")
add_executable(${Project_Name} ${SOURCE_FILES})
target_link_libraries(${Project_Name} SDL2main SDL2 OgreMain) #Ogre
Running the "generate makefile" command in the IDE completes without issue, but does not fix the problem. Additionally, clean fails, but "help" does work.
This is a problem within the IDE, it seems, because if I run make from the command line in the project root, it builds without issue.
Also, I fiddled with the file path mode setting under C/C++ -> Project Options, and it did nothing. Even set to absolute, what seems to be a relative path (CMakeFiles/Makefile2) is still in the failed command. I'm not sure if that option is expected to change that sort of reference or not.
What could be wrong with this imported project to cause this issue?
However, when I attempt to build the project, I get a rather cryptic (Java?) error message:
This is an error shown by netbeans to tell you, that it was unable to execute make command successfully. Usually this indicates a wrong setting of your (mingw-) tools.
Here are some points you can check:
Don't use make from mingw/bin, you have to use the one from mingw/msys/... There's a mingw make within mingw's msys folder, usually C:\<Path to MSYS>\<Version>\bin\make.exe - this bin-path must also be set in PATH environment variable! If MSys wasn't installed with your mingw installation, please install it.
Please check the tools set in Tools -> Options -> C/C++ -> Build Tools; you can test them by clicking Versions....
(If existing) Clean the CMake generated files and clean the cmake's cache. If not done yet, please use an out-of-source build as described here.
Can you build your project from terminal (without netbeans)?
The first directory (/C/MinGW/bin/make.exe) stands out to me as not being in Windows-format, but I am not sure if that's incorrect.
This is ok and intended by mingw - it uses linux / unix like paths.
Update
Which make program should I use?
Many MinGW users have a problem because they use mingw32-make.exe from
the MinGW installation. While this seems like the right choice, it
actually breaks the build. The problem is that this is a non-Posix
implementation of the Unix make program and doesn't work well at all.
In fact, thats why the MinGW people renamed it! They've also made a
FAQ entry explaining why you should not use mingw32-make.exe. Instead,
you should use the make.exe program from the MSYS package.
As of NetBeans 6.1, the Build Tools panel no longer allows a user to
select mingw32-make. If you choose a MinGW compiler collection it will
default to make in MSYS. If MSYS is not found, it will tell you no
make program has been found.
(http://wiki.netbeans.org/MinGWInCCDevelopmentPack)
I am trying to build a c++ implementation of hidden markov models - downloaded from
http://www.cs.au.dk/~asand/?page_id=152
I am compiling this on an ubuntu 12.04 with a g++ 4.6 compiler.
Following the instructions mentioned on the webpage, on typing
cmake .
I get the following errors,
-- Could NOT find Doxygen (missing: DOXYGEN_EXECUTABLE)
CMake Error at CMakeLists.txt:101 (message):
The Boost C++ libraries was not found. Get Boost from
http://www.boost.org/ or set the environment variable BOOST_ROOT to point
to the root of boost directory.
Could someone help me resolve these issues out.
My boost folder is situated at
/usr/local/boost_1_52_0
It's telling you to set BOOST_ROOT environment variable. So just do it:
BOOST_ROOT=/usr/local/boost_1_52_0 cmake
(prefixing a command with setting of an environment variable in posix shell sets it for just that command; cmake will remember the value in CMakeCache.txt afterwards)
I suppose the fact it didn't find doxygen does not matter. You will should still be able to build the library, you just won't be able to generate nice documentation for it, but that probably exists on the web somewhere or you can read it in the headers directly anyway.