I'm using CMake 3.23 with Visual Studio 2022. From everything I found about cmake --build command it should be running msbuild, but evidently it's running devenv instead. Is there some setting I'm not aware of? How do I get it to run msbuild so I can pass options to it?
This is my generator command:
cmake -G "Visual Studio 17" -A x64 -T v143 ..
And then cmake --build is running devenv instead of msbuild:
cmake --build . --config Release -- /verbosity:detailed
Microsoft Visual Studio 2022 Version 17.2.3.
Copyright (C) Microsoft Corp. All rights reserved.
Invalid Command Line. Unknown Switch : verbosity:detailed.
Use:
devenv [solutionfile | projectfile | folder | anyfile.ext] [switches]
CMake by default is using MSBuild and falls back to devenv if you either requested it deliberately (with CMAKE_MAKE_PROGRAM) or you have an Intel Fortran project in which case it has to use devenv.
You can check if it found MSBuild by checking the CMAKE_VS_MSBUILD_COMMAND variable. And you can force CMake to use MSBuild by setting CMAKE_MAKE_PROGRAM to the MSBuild path (although I don't know how it will behave if you have a Fortran project).
I am using Clion to work on a CMake project which needs to be built with a Visual Studio 16 2019 generator. When I run a build, Clion performs the following command:
$ cmake.exe --build C:\<PATH_TO_PROJECT>\cmake-build-release --target FooTarget --config Release
With this workflow now I would like to get verbose builds in order to troubleshoot which commands and command line arguments are being used by each build.
Is it possible to get cmake to run verbose builds while using a Visual Studio 2019 generator?
CMake supports passing generator-specific compiler flags as build tool options.
If you're using a Visual Studio generator, you can pass MsBuild command line options such as -verbosity:level with a command like:
cmake.exe --build C:\<PROJECTDIR>\cmake-build-debug --target <BUILDTARGET> --config Debug -- -verbosity:diagnostic
In Clion, just open the project's CMake settings and add -- -verbosity:diagnostic to the "build options" line edit.
I've worked in c++ for many years but I am new to CMake.
I build my app with
cmake --build build_dir --config Debug --target all -- -j 1
This works fine and builds the Debug version.
If I change the --config to anything else, for example Release with the following command:
cmake --build build_dir --config Release --target all -- -j 1
ninja says "no work to do" and exits. Running the compiled app it is clearly not optimised. There are two other options in this Cmake Project, RelWithDebug and MinSizeRel, and they act the same.
In CmakeLists.txt there is:
set(CMAKE_CONFIGURATION_TYPES "Release;Debug;MinSizeRel;RelWithDebInfo")
There are a lot of other mentions of the various types, but it's all slightly greek to me at this time.
What can I do to work out where the issue is?
I'm going to give you the full in depth answer. Just in case someone else has this confusion.
What is a generator?
Essentially a generator is the build system CMake creates. CMake doesn't directly build your project. Because CMake is a meta-build system. IE CMake is a build system that 'generates' your true build system. That's why it is called a 'generator'.
"Visual Studio 16 2019" was designed to handles multiple configurations in 1 build.
Which is why when you open a Visual Studio project created by CMake you can easily change between Debug, Release, etc.
Where as "Unix Makefiles" and "Ninja" can only handle 1 config type at a time.
This difference in build system abilities leads to slightly different CLI when running CMake.
Visual Studio 16 2019 (Multi-Config)
As mentioned before Visual Studio supports multiple config types in the build.
cmake -S . -B build/vs -G "Visual Studio 16 2019"
cmake --build build/vs --config Debug
cmake --build build/vs --config Release
In the first command you are creating the Visual Studio 2019 project.
In the second command you are actually building the binaries. And since Visual Studio projects are multi-config you don't need a different build folder for each type. Since Visual Studio handles it for you!
Ninja (Single Config)
cmake -S . -B build/ninja/ -G "Ninja" -D CMAKE_BUILD_TYPE=Debug
cmake --build build/ninja/
# Now I've updated the project to make Release binaries
cmake -S . -B build/ninja/ -D CMAKE_BUILD_TYPE=Release
cmake --build build/ninja/
In the example above you create a Ninja project for a debug build. Then you build it.
Then you create a Ninja project for a release build. Then you build it.
Notice how you have to manually specify 2 build folders for each type yourself.
Ninja Multi-Config (new in CMake 3.17)
Thanks to advances in Ninja and CMake you can create avoid the hassle of specifying the build type at project creation time. So now it's just like Visual Studio.
So now you can create a "Ninja Multi-Config" project instead of just a "Ninja" project.
cmake -S . -B build/nin -G "Ninja Multi-Config"
cmake --build build/nin --config Debug
cmake --build build/nin --config Release
Further Elaboration
Single Config Vs Multi-Config
How can you tell if your generator is Multi vs Single?
Read the docs. Or if you need to in your scripts you can check it programmatically.
You can query the global property GENERATOR_IS_MULTI_CONFIG
CMAKE_BUILD_TYPE
A minor thing to mention is that CMAKE_BUILD_TYPE doesn't do anything on multi-config generators. So avoid using it in your CMake code.
See this answer: CMAKE_BUILD_TYPE is not being used in CMakeLists.txt
I have a project, and need to set up and build an Apache24 server on windows, but there is almost non of information on that, can you give some advice?
I had to build and install Expat to get Apache running on windows 10 x64 with the instructions above. I build on Windows Visual Studio 2017 Community Edition using the x64 Native Command Prompt. (I installed all the VC and C++ modules - not sure which ones were specifically required.) Also i used the latest version of all of the software listed above so the install commands had to be adjusted accordingly. Trial by fire! Good luck.
I found the answer, after a lot of searching, I found an acceptable way to do it.
Software Requirements:
Visual Studio 2013 (I use the Community Edition)
Make a folder on C, call it BuildTools and install all the following programs there:
ActivePerl for Windows (64-bit, currently using 5.20.1.2000)
CMake for Windows (currently using 3.1.3)
GNU Awk for Windows (currently using 3.1.6-1)
GnuWin32 (any version from 2014+)
Netwide Assembler (NASM) (currently using 2.11.06)
Source Code Packages (I don't use ZLIB for Apache or OpenSSL, or LUA/LIBXML2/EXPAT, therefore these are not included in the process):
httpd-2.4.12.tar.gz
apr-1.5.1.tar.gz
apr-util.1.5.4.tar.gz
openssl-1.0.2a.tar.gz (yes it works with 1.0.2a!)
pcre-8.36.tar.gz
Here are the steps:
Extract all packages into their separate folders in your preferred source tree (e.g. C:\Development\Apache24\src)
Create custom build folders for Apache, PCRE, APR and APR-Util in your preferred build folder (e.g. C:\Development\Apache24\build
Your folder structure should resemble the below:
Make the following file changes so that ApacheMonitor gets built (without the Manifest error):
C:\Development\Apache24\src\httpd-2.4.12\CMakeLists.txt
Uncomment the section to build the ApacheMonitor utility (lines 769-775)
Find the following lines below, they will be in comments
# getting duplicate manifest error with ApacheMonitor
ADD_EXECUTABLE(ApacheMonitor support/win32/ApacheMonitor.c support/win32/ApacheMonitor.rc)
SET(install_targets ${install_targets} ApacheMonitor)
SET(install_bin_pdb ${install_bin_pdb} ${PROJECT_BINARY_DIR}/ApacheMonitor.pdb)
SET_TARGET_PROPERTIES(ApacheMonitor PROPERTIES WIN32_EXECUTABLE TRUE)
SET_TARGET_PROPERTIES(ApacheMonitor PROPERTIES COMPILE_FLAGS "-DAPP_FILE -DLONG_NAME=ApacheMonitor -DBIN_NAME=ApacheMonitor.exe / ${EXTRA_COMPILE_FLAGS}")
TARGET_LINK_LIBRARIES(ApacheMonitor ${EXTRA_LIBS} ${HTTPD_SYSTEM_LIBS} comctl32 wtsapi32)
Also
C:\Development\Apache24\src\httpd-2.4.12\support\win32\ApacheMonitor.rc
Comment out the line that includes ApacheMonitor.manifest (line 29)
//CREATEPROCESS_MANIFEST_RESOURCE_ID RT_MANIFEST "ApacheMonitor.manifest"
4.1 Create a set_path.bat file with the following code:
SET VC_HOME=c:\Program Files (x86)\Microsoft Visual Studio 13.0\VC
call VC_HOME\vcvarsall amd64
SET BUILD_ROOT=C:\BuildTools
SET PATH=%PATH%;%BUILD_ROOT%\cmake\bin
SET PATH=%PATH%;%BUILD_ROOT%\gawk\bin
SET PATH=%PATH%;%BUILD_ROOT%\nasm
SET PATH=%PATH%;%BUILD_ROOT%\perl\bin
You will need to run that file later in the process.
From the Start menu, launch the VS2013 x64 Native Tools Command Prompt found under Visual Studio 2013->Visual Studio Tools. Alternatively, but not recommended, from a Windows Command Prompt.
5.1 Go to GnuWin32, find his lib and the include folder, and copy their content to the BuildTools/perl/lib folder, this should resolve some errors that came up in the process while I was doing this
5.2 This step, you can skip now, BUT, if there is an error that includes the expat.h and the expath_external.h files, Find an older version of Apache, and copy its expat_external.h to the apache24/include folder
Find expat.h file on this site
https://github.com/apache/apr-util/blob/0.9.x/xml/expat/lib/expat.h
copy its content over the file, you find in apache24/include folder Find an older version of Apache (don't know exactly witch version), and copy its expat_external.h to the apache24/include folder
Find expat.h file on this site
https://github.com/apache/apr-util/blob/0.9.x/xml/expat/lib/expat.h
copy its content over the file, you find in apache24/include folder
5.3. Find the set_path.bat folder from the console and run it.
this you need to do, to be able to run the next steps
Navigate into the build sub-folder for PCRE, run CMAKE to generate a suitable Makefile, then compile and install
cd /D C:\Development\Apache24\build\pcre
cmake -G "NMake Makefiles" -DCMAKE_INSTALL_PREFIX=C:\Apache24 -DCMAKE_BUILD_TYPE=RelWithDebInfo -DBUILD_SHARED_LIBS=ON -DPCRE_BUILD_TESTS=OFF -DPCRE_BUILD_PCRECPP=OFF -DPCRE_BUILD_PCREGREP=OFF -DPCRE_SUPPORT_PCREGREP_JIT=OFF -DPCRE_SUPPORT_UTF=ON -DPCRE_SUPPORT_UNICODE_PROPERTIES=ON -DPCRE_NEWLINE=CRLF -DINSTALL_MSVC_PDB=OFF ..\..\src\pcre-8.36
nmake
nmake install
Navigate into the source sub-folder for OpenSSL, configure the build environment for compiling with NASM, then compile and install
cd /D C:\Development\Apache24\src\openssl-1.0.2a
perl Configure VC-WIN64A --prefix=C:\Apache24 --openssldir=C:\Apache24\conf enable-camellia no-idea no-mdc2 no-ssl2 no-ssl3 no-zlib
ms\do_win64a.bat
nmake /f ms\ntdll.mak
nmake /f ms\ntdll.mak install
Navigate into the build sub-folder for APR, run CMAKE to generate a suitable Makefile, then compile and install
cd /D C:\Development\Apache24\build\apr
cmake -G "NMake Makefiles" -DCMAKE_INSTALL_PREFIX=C:\Apache24 -DCMAKE_BUILD_TYPE=RelWithDebInfo -DMIN_WINDOWS_VER=0x0600 -DAPR_HAVE_IPV6=ON -DAPR_INSTALL_PRIVATE_H=ON -DAPR_BUILD_TESTAPR=OFF -DINSTALL_PDB=OFF ..\..\src\apr-1.5.1
nmake
nmake install
Navigate into the build sub-folder for APR-Util, run CMAKE to generate a suitable Makefile, then compile and install
cd /D C:\Development\Apache24\build\apr-util
cmake -G "NMake Makefiles" -DCMAKE_INSTALL_PREFIX=C:\Apache24 -DOPENSSL_ROOT_DIR=C:\Apache24 -DCMAKE_BUILD_TYPE=RelWithDebInfo -DAPU_HAVE_CRYPTO=ON -DAPR_BUILD_TESTAPR=OFF -DINSTALL_PDB=OFF ..\..\src\apr-util-1.5.4
nmake
nmake install
Navigate into the build sub-folder for Apache, run CMAKE to generate a suitable Makefile, then compile and install
cd /D C:\Development\Apache24\build\httpd
cmake -G "NMake Makefiles" -DCMAKE_INSTALL_PREFIX=C:\Apache24 -DCMAKE_BUILD_TYPE=RelWithDebInfo -DENABLE_MODULES=i -DINSTALL_PDB=OFF ..\..\src\httpd-2.4.12
nmake
nmake install
Finally, confirm everything is working
cd /D C:\Apache24\bin
openssl version
httpd -V
These are the steps and the problems I encountered, and I followed the steps from this site:
https://www.apachelounge.com/viewtopic.php?t=6462
Also I added a few more steps and solutions that I needed to do to make it work.
I hope this will help someone else in the future.
I have been following instructions from the FAQ: Is there an option to produce more 'verbose' compiling?. I have now:
$ cat C:/Program Files/CMake 2.8/share/cmake-2.8/Modules/Platform/Windows.cmake
[...]
# uncomment these out to debug nmake and borland makefiles
set(CMAKE_START_TEMP_FILE "")
set(CMAKE_END_TEMP_FILE "")
set(CMAKE_VERBOSE_MAKEFILE 1)
I then regenerate my project, and run nmake:
> cmake --version
cmake version 2.8.12.2
> cmake -G"NMake Makefiles" ..\project
> nmake VERBOSE=1
[...]
[ 73%] Building CXX object apps/foobar/CMakeFiles/bla.dir/my.cpp.obj
cd C:\Dashboards\MyTests\project-build-debug-vista32-nightly\apps\foobar
C:\PROGRA~1\MICROS~1.0\VC\bin\cl.exe #C:\Users\voxxl\AppData\Local\Temp\nm1362.tmp
Is there a way to have access to the full cl command line ?
On Windows (XP or greater), Command lines are limited in length to 8,191 bytes.
Windows compiler toolsets get around this by allowing the #filepath syntax on the command line.
So VERBOSE=1 is less useful on Windows. But you can always check command line in generated *.make files
For example (path used from question):
apps/foobar/CMakeFiles/bla.dir/build.make
apps/foobar/CMakeFiles/bla.dir/flags.make