This question already has answers here:
How to determine current build type of visual studio with cmake
(2 answers)
Closed 1 year ago.
In my project I want to set up a path for installation target based on current configuration type:
project(mylib VERSION 1.0)
set(INSTALL_DIR ${CMAKE_INSTALL_PREFIX}/mylib/${PROJECT_VERSION}/${CMAKE_BUILD_TYPE})
install(TARGETS mylib ARCHIVE DESTINATION ${INSTALL_DIR})
What I get is:
C:/install/mylib/1.0/mylib.lib
I can't figure out why CMAKE_BUILD_TYPE is empty.
Seemingly trivial situation, but I wasted already an hour to google a solution. Any idea?
I'm doing INSTALL on Visual Studio auto-generated project, but I have tried it also from a command line. Neither works:
cmake -DCMAKE_INSTALL_PREFIX="C:\install"
-DCMAKE_GENERATOR_PLATFORM=Win32 .. cmake --install . --config Release
Here's a minimal example:
cmake_minimum_required(VERSION 3.21)
project(mylib VERSION 1.0)
add_library(mylib mylib.cpp)
include(GNUInstallDirs)
install(
TARGETS mylib
ARCHIVE DESTINATION ${CMAKE_INSTALL_LIBDIR}/mylib/${PROJECT_VERSION}/$<CONFIG>
)
Where mylib.cpp is just int mylib() { return 42; } (just to appease the compiler).
You can test this in a platform-independent way via:
$ cmake -G "Ninja Multi-Config" -S . -B build
...
$ cmake --build build --config Debug
...
$ cmake --build build --config Release
...
$ cmake --install build --config Debug --prefix install
-- Installing: /path/to/install/lib/mylib/1.0/Debug/libmylib.a
$ cmake --install build --config Release --prefix install
-- Installing: /path/to/install/lib/mylib/1.0/Release/libmylib.a
The key is to use the $<CONFIG> generator expression. It is never correct to read CMAKE_BUILD_TYPE without first confirming that a single config generator is active (by checking the GENERATOR_IS_MULTI_CONFIG global property). Even then, it's a bad idea since you don't want your CMakeLists.txt to be highly generator dependent.
Related
I tried using a demo to compile tbb in my project.
Link of the demo https://www.selectiveintellect.net/blog/2016/7/29/using-cmake-to-add-third-party-libraries-to-your-project-1
IDE for me is VS2013 and get an error about command 'make'
Performing build step for 'tbb44'
2> CMake Error at F:/CPPs/FAsT-Match-master/build/tbb44/src/tbb44-stamp/tbb44-build-Debug.cmake:49 (message):
2> Command failed: 2
2>
2> 'make' 'tbb_build_prefix=tbb44'
The original command is generated via tbb.cmake, for which it looks like
ExternalProject_Add(${TBB_PREFIX}
PREFIX ${TBB_PREFIX}
URL ${TBB_URL}
URL_MD5 ${TBB_URL_MD5}
CONFIGURE_COMMAND ""
# BUILD_COMMAND ${TBB_MAKE} -j${NCPU} tbb_build_prefix=${TBB_PREFIX}
BUILD_COMMAND ${TBB_MAKE} tbb_build_prefix=${TBB_PREFIX}
The one commented is the original and the one behind is modified.
Is this the problem of MSVC?
That blog post is just completely wrong. TBB comes with its own CMake build now, so there's absolutely no reason to go through ExternalProject like this.
Here's how I built it from source, using Visual Studio 2019 (the instructions should be pretty much the same). From a developer command prompt, using CMake 3.20:
D:\>git clone https://github.com/oneapi-src/oneTBB
D:\>cmake -S oneTBB -B oneTBB-build -DTBB_TEST=OFF
D:\>cmake --build oneTBB-build --config Release
D:\>cmake --build oneTBB-build --config Debug
D:\>cmake --install oneTBB-build --prefix oneTBB-install --config Release
D:\>cmake --install oneTBB-build --prefix oneTBB-install --config Debug
Setting TBB_TEST to OFF saves a lot of time waiting on TBB's tests to build. These commands install the Debug and Release binaries to D:\oneTBB-install. Of course, you can place this folder anywhere you like.
Once this is done, you may use your new TBB build from your project like so:
cmake_minimum_required(VERSION 3.20)
project(TBB-test)
find_package(TBB REQUIRED)
add_executable(main main.cpp)
target_link_libraries(main PRIVATE TBB::tbb)
The TBB package also includes libraries TBB::tbbmalloc and TBB::tbbmalloc_proxy.
When you build your project, you may point find_package to your TBB installation by setting the CMake variable TBB_ROOT to D:/oneTBB-install at the command line via:
D:\>cmake -S myProject -B myProject-build -DTBB_ROOT=D:/oneTBB-install
First we build libssh2 with the WinCNG backend using msvc:
cmake . -DCRYPTO_BACKEND=WinCNG -DCMAKE_BUILD_TYPE=Release -DBUILD_SHARED_LIBS=ON -DCMAKE_INSTALL_PREFIX=%LIBSSH2%
cmake --build . --target install
libgit2 docs say all we have to do is to set DEMBED_SSH_PATH, although it fails to mentation what to set it to. Maybe it's so obvious that it seems irrelevant. However: I'm not a C guy and have no clue of the cmake build process. From what I understand the folder where the result of the previous built resides with all it's subfolders such as include and bin should be the correct path, so using %LIBSSH2% should be fine.
When finally trying to build libgit2 running
cmake . -DBUILD_CLAR=OFF -DCMAKE_BUILD_TYPE=Release -DEMBED_SSH_PATH=%LIBSSH2% -DCMAKE_INSTALL_PREFIX="%LIBGIT2%"
cmake --build . --target install
It'll fail because it's unable to find the links to the header files / binaries. We see things along the line of:
error LNK2019: unresolved external symbol libssh2_init referenced in function
I already tried replacing the paths backslashes \ with normal slashes /, since this seems to be a common issue. I also tried explicitly setting
set CMAKE_INCLUDE_PATH=%LIBSSH2%/include
set CMAKE_LIBRARY_PATH=%LIBSSH2%/lib
both faild with the same result.
Can anyone provide a reproducible way to compile libgit2 with embedded libssh2?
Using EMBED_SSH_PATH means libssh2 sources will be compiled at the same time as libgit2s. This means you don't actually have to compile libssh2 at all.
I managed to get it to compile successfully by downloading the source for libssh2 and libgit2, then running the following commands:
cd libgit2
mkdir build
cd build
cmake .. -DBUILD_CLAR=OFF -DCMAKE_BUILD_TYPE=Release -DEMBED_SSH_PATH="C:/path-to-ssh/libssh2" -DCMAKE_INSTALL_PREFIX="%LIBGIT2%"
cmake --build . --target install
Internally, it looks for all files that match ${EMBED_SSH_PATH}/src/*.cif EMBED_SSH_PATH is set.
As for using WinCNG as the backend, using embedded SSH creates this file (libssh2_config.h) in the libssh2 directory:
#define HAVE_WINCNG
#define LIBSSH2_WINCNG
#include "../win32/libssh2_config.h"
I assume that means it is already the default backend for an embedded install.
Its been a While that I tried to build clang from source code.
I tried with 2 platforms
a> Ubuntu
b> Windows
I am following the link http://clang.llvm.org/docs/LibASTMatchersTutorial.html
Ubuntu
$ mkdir build
$ cd build
$ cmake -GNinja -DLLVM_ENABLE_PROJECTS="clang;clang-tools-extra" -DCMAKE_BUILD_TYPE=Release -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++ /path/to/source/llvm
After this in build directory ninja.build files generated along with some more folder
$ ninja after this command inside build directory bin folder can be seen and it contains all the clang executables clang,clang++,clang-check and many more.
Windows
I tried every option that is available to build clang from source
I am trying on developer command prompt and also I am having VS Express edition
> mkdir build
> cd build
> cmake -GNinja -DCMAKE_BUILD_TYPE=release -DLLVM_ENABLE_PROJECTS="clang;clang-tools-extra" -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++ path-to-llvm
It throws error
Host compiler appears to require libatomic,but cannot find it.
So I tried in the another way by making DCMAKE_CXX_COMPILER and DCMAKE_C_COMPILER as clang-cl.exe
> cmake -GNinja -DCMAKE_BUILD_TYPE=release -DLLVM_ENABLE_PROJECTS="clang;clang-tools-extra" -DCMAKE_C_COMPILER=clang-cl.exe -DCMAKE_CXX_COMPILER=clang-cl.exe path-to-llvm
It didnt show any error at first but later while building
atlbase.h file not found
Why it is that much difficult to build clang from source on windows.?
Is this the correct procedure that I am doing?
Kindly help with any solution.
I want to build openssl and link my project against it. In my project, I have a library called net which is the part that uses openssl. So in my net\CMakeList, I added
include_directories(
../
+ ../../../ext/openssl/inc32/
)
add_library(net STATIC ${sources})
+ ADD_DEPENDENCIES(net openssl)
In my ext folder that is used for organizing all external library, I have a fresh unzipped openssl source code in a folder named openssl. Then I edited ext\CmakeList
message(STATUS "Configuring OpenSSL")
set(openssl_dir openssl)
if (CMAKE_CL_64)
include(ExternalProject)
set(OPENSSL_CONFIGURE perl\ Configure\ VC-WIN64A)
set(OPENSSL_MAKE ms\\do_win64a\ &&\ nmake\ -f\ ms\\ntdll.mak)
ExternalProject_Add(openssl
PREFIX openssl
#-- Download Step ----------
SOURCE_DIR ${CMAKE_SOURCE_DIR}/ext/openssl
#--Configure step ----------
CONFIGURE_COMMAND ${OPENSSL_CONFIGURE}
#--Build Step ----------
BUILD_COMMAND ${OPENSSL_MAKE}
BUILD_IN_SOURCE 1
#--install Step ----------
INSTALL_COMMAND ""}
)
endif()
When I built, the compiler complained the it can't find include files, and the openssl source code was not built at all, since there is no out32dll and inc32.
My question is: When does ExternalProject_Add actually build the project? If I make my net library depending on openssl, does it mean when I build net it would need to check and build openssl first?
ExternalProject use add_custom_target internally to create project and according to its document
By default nothing depends on the custom target. Use ADD_DEPENDENCIES
to add dependencies to or from other targets.
So if no project depend on it, it will not build by default.
When this ExternalProject_Add actually builds the project?
At build time(not at cmake time).
If I make my net library depends on openssl, does it mean when I build net it would need to check and build openssl first?
No. Since you make the dependency, cmake will handle it and openssl will be build before your library.
PS: There's still a lot of work to do. Because cmake doesn't know where the openssl result is, your project may run into link error. Here is a good example from the answer of "What is the best way to build boost with cmake".It use add_library with IMPORTED GLOBAL and set_target_properties with IMPORTED_LOCATION_* to solve the problem
Install missed
First of all I think you missed an install step. See documentation:
nmake -f "ms\ntdll.mak" install
So simplified version of ExternalProject_Add is:
ExternalProject_Add(
OpenSSL
URL https://github.com/openssl/openssl/archive/OpenSSL_1_0_1h.tar.gz
CONFIGURE_COMMAND perl Configure VC-WIN64A "--prefix=${CMAKE_INSTALL_PREFIX}"
BUILD_COMMAND "ms\\do_win64a.bat"
COMMAND nmake -f "ms\\ntdll.mak"
BUILD_IN_SOURCE 1
INSTALL_COMMAND nmake -f "ms\\ntdll.mak" install
)
Find OpenSSL
Second, if you want to find openssl libraries and headers, you need to use find_package(OpenSSL) command:
find_package(OpenSSL REQUIRED)
message("Libs: ${OPENSSL_LIBRARIES}")
message("Includes: ${OPENSSL_INCLUDE_DIR}")
Builds
Now, if you put all this commands together in one project configure step will fail :) Because it's not how ExternalProject designed. Superbuild that made by few or one ExternalProject_Add commands must be configured first, then build step will install the libraries from external archives. This will conflict with your project, because openssl libraries can't be found - they are not installed by superbuild yet.
Fix
Split cmake code. Run superbuild first (i.e. download and install openssl):
> cmake -Hsuperbuild -B_builds\superbuild "-GVisual Studio 12 2013 Win64" -DCMAKE_INSTALL_PREFIX=ext\install
# note, no ext\install directory yet
> cmake --build _builds\superbuild
# install done, libraries can be found in ext\install
Then build your project, note that the libraries found on configure step:
> cmake -Huse -B_builds\use "-GVisual Studio 12 2013 Win64" -DCMAKE_INSTALL_PREFIX=ext\install
-- Found OpenSSL: .../ext/install/lib/ssleay32.lib;.../ext/install/lib/libeay32.lib (found version "1.0.1h")
Libs: .../ext/install/lib/ssleay32.lib;.../ext/install/lib/libeay32.lib
Includes: .../ext/install/include
> cmake --build _builds\use
# OK
Experimental
I have an experimental project that wrap all of this noise in one command (Windows tested on Visual Studio 2013):
hunter_add_package(OpenSSL)
find_package(OpenSSL REQUIRED)
https://github.com/ruslo/hunter
I am trying to build a project in Release mode. By default it is built in debug mode. I am setting the variable CMAKE_BUILD_TYPE to "Release" in CMakeLists.txt. But it is still building the project in debug mode.
When I pass "Release" as the build type in the CMake command, it still does not work.
The CMake command that I am using is:
cmake -G"Visual Studio 10" -DCMAKE_BUILD_TYPE=Release
-H"source_path" -B"Build path"
Please provide a solution if any.
To change the build type, on Windows, it must be done at build time:
cmake --build {DIR} --config Release
By default it's Debug. I'm still looking for a way of changing this default. CMAKE_BUILD_TYPE doesn't work of course, and tweaking CMAKE_CONFIGURATION_TYPES doesn't work either, obviously for the same reason, they only apply for Unix makefiles, not for Visual projects.
I checked it with Visual Studio 2015 and cmake 3.3 .
Short answer
Link
cmake --build {BUILD_DIR_PATH} --target ALL_BUILD --config {BUILD_TYPE}
Example
cmake --build . --target ALL_BUILD --config Release
Long answer
cmake -G{GENERATOR_NAME} -B{BUILD_DIR_PATH} -H{SOURCE_DIR_PATH}
cmake --build {BUILD_DIR_PATH} --target ALL_BUILD --config {BUILD_TYPE}
Example
cmake -GVisual Studio 14 -Bbuild/win32/x86 -H.
cmake --build build/win32/x86 --target ALL_BUILD --config Release
Additional info
"-G" - specifies the generator name
"-B" - specifies path to the build folder
"-H" - specifies path to the source folder
You cannot set the default build type for Visual Studio from the command line.
CMake's Visual Studio Generators will generate the four standard profiles (Debug, RelWithDebInfo, MinSizeRel and Release) and you have to choose the one you want to build from within VS. This is because the information about the active configuration is not part of the project files generated by CMake, but part of the .suo file generated by VS.
If you want an automated build of a particular configuration, use MSBuild instead of VS which allows you to specify a configuration on the command line.
Tried the things below which worked for me to build the binaries in release/debug mode in Windows.
Added the following line in the root CMakeLists.txt file, just above the project command:
SET(CMAKE_CONFIGURATION_TYPES ${CMAKE_BUILD_TYPE} CACHE STRING "" FORCE)
Used the following command for setting the release mode configuration:
cmake -DCMAKE_BUILD_TYPE=Release ..
Used this command to build the same in Release mode:
cmake --build . --config Release
You can repeat the same procedure for debug mode as well, it works.
Bit late, but I found this worked for me and was quite clean:
This means that just calling cmake builds in release mode, but if you want debug mode just call cmake -DCMAKE_BUILD_TYPE=Debug
if(NOT CMAKE_BUILD_TYPE)
set(CMAKE_BUILD_TYPE "Release" CACHE STRING "Choose Release or Debug" FORCE)
endif()
If your generator is a single-config generator like "Unix Makefiles" or "Ninja", then the build type is specified by the CMAKE_BUILD_TYPE variable, which can be set in the configure command by using -DCMAKE_BUILD_TYPE:STRING=Release.
For multi-config generators like the Visual Studio generators and "Ninja Multi-Config", the config to build is specified in the build command using the --config argument argument like --config Release. A default value can currently be specified at configure time for the Ninja Multi-Config generator by setting the value of the CMAKE_DEFAULT_BUILD_TYPE variable, which will be used if the --config argument isn't passed to the build command. At the current time, a default cannot be set for Visual Studio generators.
Use it as you do it but in the root cmake file add the following before the project keyword
SET(CMAKE_CONFIGURATION_TYPES ${CMAKE_BUILD_TYPE} CACHE STRING "" FORCE)
PROJECT(MY_PROJECT)#It's here just to show where you should add it.