How to set compiler options with CMake in Visual Studio 2017 - visual-c++

Visual Studio 2017 comes with full CMake integration. To learn about this combination, I was starting with this basic sample:
# CMakeLists.txt
cmake_minimum_required(VERSION 3.8)
project(foo)
add_executable(foo foo.cpp)
and
// foo.cpp
int main() {}
This properly generates build scripts, and compiles and links with no issues. That was easy.
Trying to set compiler options, on the other hand, turned out to be anything but trivial. In my case I was attempting to set the warning level to 4.
The obvious solution
add_compile_options("/W4")
didn't pan out as expected. The command line passed to the compiler now contains both /W4 (as intended) as well as /W3 (picked up from somewhere else), producing the following warning:
cl : Command line warning D9025: overriding '/W3' with '/W4'
To work around this, I would need to replace any incompatible compiler option(s) instead of just adding one. CMake does not provide any immediate support for this, and the standard solution (as this Q&A suggests) seems to be:
if(CMAKE_CXX_FLAGS MATCHES "/W[0-4]")
string(REGEX REPLACE "/W[0-4]" "/W4" CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS}")
else()
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} /W4")
endif()
This, however, has two issues:
It sets the global CMAKE_CXX_FLAGS, applying to all C++ targets. This may not be intended (not an issue for me right now).
It doesn't scale. For every compiler option to add, you would have to read up on incompatible options, and manually strip those first. This will inevitably fail1.
My question is two-fold:
Where does the CMake integration pick up default settings from, and can this be controlled?
How do you set compiler options in general? (If this is too broad a topic, I'd be happy for help on setting the warning level only.)
1 Incidentally, the solution I replicated fails to account for the /Wall option, that is incompatible with /W4 as well.

The default settings for the compiler are picked up from standard module files located in the Modules directory of the CMake installation. The actual module file used depends on both the platform and the compiler. E.g., for Visual Studio 2017, CMake will load the default settings from the file Windows-MSVC.cmake and language specific settings from Windows-MSVC-C.cmake or Windows-MSVC-CXX.cmake.
To inspect the default settings, create a file CompilerOptions.cmake in the project directory with the following contents:
# log all *_INIT variables
get_cmake_property(_varNames VARIABLES)
list (REMOVE_DUPLICATES _varNames)
list (SORT _varNames)
foreach (_varName ${_varNames})
if (_varName MATCHES "_INIT$")
message(STATUS "${_varName}=${${_varName}}")
endif()
endforeach()
Then initialize the CMAKE_USER_MAKE_RULES_OVERRIDE variable in your CMakeLists.txt:
# CMakeLists.txt
cmake_minimum_required(VERSION 3.8)
set (CMAKE_USER_MAKE_RULES_OVERRIDE "${CMAKE_CURRENT_LIST_DIR}/CompilerOptions.cmake")
project(foo)
add_executable(foo foo.cpp)
When the project is configured upon opening the directory using Open Folder in Visual Studio 2017, the following information will be shown in the IDE's output window:
...
-- CMAKE_CXX_FLAGS_DEBUG_INIT= /MDd /Zi /Ob0 /Od /RTC1
-- CMAKE_CXX_FLAGS_INIT= /DWIN32 /D_WINDOWS /W3 /GR /EHsc
-- CMAKE_CXX_FLAGS_MINSIZEREL_INIT= /MD /O1 /Ob1 /DNDEBUG
-- CMAKE_CXX_FLAGS_RELEASE_INIT= /MD /O2 /Ob2 /DNDEBUG
-- CMAKE_CXX_FLAGS_RELWITHDEBINFO_INIT= /MD /Zi /O2 /Ob1 /DNDEBUG
...
So the warning setting /W3 is picked up from the CMake variable CMAKE_CXX_FLAGS_INIT which then applies to all CMake targets generated in the project.
To control the warning level on the CMake project or target level, one can alter the CMAKE_CXX_FLAGS_INIT variable in the CompilerOptions.cmake by adding the following lines to the file:
if (MSVC)
# remove default warning level from CMAKE_CXX_FLAGS_INIT
string (REGEX REPLACE "/W[0-4]" "" CMAKE_CXX_FLAGS_INIT "${CMAKE_CXX_FLAGS_INIT}")
endif()
The warning flags can then be controlled by setting the target compile options in CMakeLists.txt:
...
add_executable(foo foo.cpp)
target_compile_options(foo PRIVATE "/W4")
For most CMake projects it makes sense to control the default compiler options in a rules override file instead of manually tweaking variables like CMAKE_CXX_FLAGS.
When making changes to the CompilerOptions.cmake file, it is necessary to recreate the build folder. When using Visual Studio 2017 in Open Folder mode, choose the command Cache ... -> Delete Cache Folders from the CMake menu and then Cache ... -> Generate from the CMake menu to recreate the build folder.

Turning my comment into an answer
CMake does come with some compiler switches preset. For visual studio those are mainly standard link libraries, warning levels, optimization levels, exception handling, debug information and platform specific defines.
What you now have to differentiate when you want to change a CMake generated compiler settings are the following use cases:
Additional compiler flags CMake does not define vs. changing CMake's preset settings
Project default settings vs. project user defined settings
So let's discuss common solutions for those cases.
User changes/adds to Project/CMake Compiler Flags Defaults
The standard way would be to modify the cached compiler flags variables by using tools shipped with CMake like cmake-gui and ccmake.
To achieve this in Visual Studio you would have to:
CMake / Cache / View CMakeCache
Manually change e.g. CMAKE_CXX_FLAGS to /Wall
CMakeCache.txt
//Flags used by the compiler during all build types.
CMAKE_CXX_FLAGS:STRING= /DWIN32 /D_WINDOWS /Wall /GR /EHsc
CMake / Cache / Generate
Or you preset the CMAKE_CXX_FLAGS cache variable via a CMakeSettings.json file:
CMake / Change CMake Settings
Force the cache entry with -DCMAKE_CXX_FLAGS:STRING=... in cmakeCommandArgs
CMakeSettings.json
{
// See https://go.microsoft.com//fwlink//?linkid=834763 for more information about this file.
"configurations": [
{
"name": "x86-Debug (all warnings)",
"generator": "Visual Studio 15 2017",
"configurationType": "Debug",
"buildRoot": "${env.LOCALAPPDATA}\\CMakeBuild\\${workspaceHash}\\build\\${name}",
"cmakeCommandArgs": "-DCMAKE_CXX_FLAGS:STRING=\"/DWIN32 /D_WINDOWS /Wall /GR /EHsc\"",
"buildCommandArgs": "-m -v:minimal"
}
]
}
If you deliver this CMakeSettings.json file with your CMake project it gets permanent
Project changes to CMake Compiler Flags Defaults
If you want to keep most of CMake's compiler flags in place, #sakra's answer is definitely the way to go.
For my VS projects I've put the CXX flag settings into a toolchain file coming with the project itself. Mainly to freeze those settings and don't have a dependency the CMake version used or any environment variables set.
Taking the example from above that would look like:
VS2017Toolchain.cmake
set(CMAKE_CXX_FLAGS "/DWIN32 /D_WINDOWS /Wall /GR /EHsc" CACHE INTERNAL "")
CMakeSettings.json
{
// See https://go.microsoft.com//fwlink//?linkid=834763 for more information about this file.
"configurations": [
{
"name": "x86-Debug (all warnings)",
"generator": "Visual Studio 15 2017",
"configurationType": "Debug",
"buildRoot": "${env.LOCALAPPDATA}\\CMakeBuild\\${workspaceHash}\\build\\${name}",
"cmakeCommandArgs": "-DCMAKE_TOOLCHAIN_FILE:FILEPATH=\"${projectDir}\\VS2017Toolchain.cmake\"",
"buildCommandArgs": "-m -v:minimal"
}
]
}
References
Visual C++ Team Blog: CMake support in Visual Studio – the Visual Studio 2017 RC update
set diagnostics:caret from CMakeLists.txt
Is Cmake set variable recursive?
Passing compiler options cmake

In CMake 3.15, CMake introduced a fix for this MSVC-specific warning:
cl : Command line warning D9025: overriding '/W3' with '/W4'
and the compiler warning flags (like /W3) are no longer automatically added. So by upgrading to CMake 3.15 or greater, this warning should no longer appear. From the docs:
When using MSVC-like compilers in CMake 3.14 and below, warning flags like /W3 are added to CMAKE_<LANG>_FLAGS by default. This is problematic for projects that want to choose a different warning level programmatically. In particular, it requires string editing of the CMAKE_<LANG>_FLAGS variables with knowledge of the CMake builtin defaults so they can be replaced.
CMake 3.15 and above prefer to leave out warning flags from the value of CMAKE_<LANG>_FLAGS by default.
Along with this fix, CMake introduced policy CMP0092, which allows you to switch back to the OLD behavior (adding the warning flags by default) if necessary.

Related

Visual C++ 2017 link error due to -Ot flag?

I am trying to get a Visual Studio 2017 project to link, but I'm stuck on the following linker error:
LINK : fatal error C1007: unrecognized flag '-Ot' in 'p2'
I've read questions on what the cause could be, but I couldn't come to a solution for my project.
The details are that, due to an external component we have no control over (component A), this Visual Studio 2017 project is forced to use the v14.13 version of the C++ toolchain, i.e. not the latest one (v14.14). However, the latest release of another external precompiled static lib we have no control over either (component B), is built with the v14.14 version (I checked via a dumpbin extract of the debug version of the lib). Switching my project over to the v14.14 toolchain indeed makes the link error go away on component B, but this unfortunately isn't a solution for me due to component A. Taking an earlier version of component B isn't desirable either, since we need the functionality in the latest release...
However, what strikes me, is that the /Ot ("optimize for speed") flag has been around since the middle ages... Why wouldn't v14.13 recognize it? Or is it just an (awkwardly manifested) matter of a mismatched obj file layout due to the version differences? And, probably related, what does the 'p2' stand for anyway?
Update
I've checked the linker output by using the /verbose flag, and all seems normal (3600 lines of Searching <lib>, Found <function>, Referenced in <obj> and Loaded <lib>).
Right up until the end that is, where I get the following 6 lines:
1> Searching C:\PathToExternalLib\TheirStatic.lib:
1> Found UsedFunctionName
1> Referenced in MyOwnStatic.lib(MyOwnCompileUnit.obj)
1>LINK : fatal error C1007: unrecognized flag '-Ot' in 'p2'
1>LINK : fatal error LNK1257: code generation failed
1>Done building project "MyProject.vcxproj" -- FAILED.
And that's that.
When visiting the command line setting of the link properties of the project, the only thing listed is (broken up in separate lines for convenience):
/OUT:"MyProject.dll"
/MANIFEST
/NXCOMPAT
/PDB:"MyProject.pdb"
/DYNAMICBASE "C:\PathToMyStatic.lib"
/IMPLIB:"MyProject.lib"
/DLL
/MACHINE:X64
/PGD:"MyProject.pgd"
/MANIFESTUAC:"level='asInvoker' uiAccess='false'"
/ManifestFile:"MyProject.prm.intermediate.manifest"
/ERRORREPORT:PROMPT
/NOLOGO
/LIBPATH:"C:\PathToExternalStaticLib"
/LIBPATH:"C:\PathToAnotherExternalStaticLib"
/TLBID:1
So no trace of any -Ot flag there as well...?
I had this problem. LINK : fatal error C1007: unrecognized flag '-Ot' in 'p2'
while building a project with Visual Studio 2015.
I had to rebuild any library or sub library the project linked to which were built with Visual Studio 2017.
Once I rebuild the dependent libraries with Visual Studio 2015 the first project was able to link against them.
project
--------\
---------lib1(unable to rebuild lib1 until its dependencies were also rebuilt with VS2015
--------------\lib_linked_by_lib1_which_was_build_with_VS2017_and_had_to_be_rebuilt
--------------\another_lib_which_had_to_be_rebuilt_for_lib1_with_VS2015
--------\lib2
--------\lib3

Variables are empty in toolchain file

I try to use MSVC and MSVC_VERSION in toolchain file -
cmake-toolchain-file.cmake
message (STATUS "Toolchain MSVC=${MSVC} MSVC_VERSION=${MSVC_VERSION}")
CMakeLists.txt
message (STATUS "Project MSVC=${MSVC} MSVC_VERSION=${MSVC_VERSION}")
Output is
> cmake .. -DCMAKE_TOOLCHAIN_FILE=../cmake/cmake-toolchain-file.cmake
-- Toolchain MSVC= MSVC_VERSION=
-- Project MSVC=1 MSVC_VERSION=1800
-- Bulding target for: windows-x86
-- Configuring done
-- Generating done
-- Build files have been written to: D:/test/build
Is it normal behavior that I get MSVC and MSVC_VERSION from toolchain file empty?
Is it normal behavior that I get MSVC and MSVC_VERSION from toolchain file empty?
Yes. Variables initialized after project command. This is where toolchain read also. Try to add some extra messages:
cmake_minimum_required(VERSION 3.0)
message(STATUS "Before project: MSVC(${MSVC})")
project(Foo)
message(STATUS "After project: MSVC(${MSVC})")
Result:
-- Before project: MSVC()
-- Toolchain MSVC()
-- Toolchain MSVC()
...
-- After project: MSVC(1)
-- Configuring done
-- Generating done
So I guess you have one hidden question in mind:
Is it confusing?
Yes, for the Visual Studio generators. Since usually you can set some critical stuff like path to compiler in toolchain it doesn't make sense to read compiler-related variables like CMAKE_CXX_COMPILER_ID before toolchain processed, i.e. before project command. But when you set generator to Visual Studio your compiler is always MSVC. This gives you a hint for the workaround. Just check CMAKE_GENERATOR variable in toolchain instead of MSVC_VERSION (though this will not work for NMake generator of course):
if("${CMAKE_GENERATOR}" STREQUAL "Visual Studio 12 2013")
message("Toolchain: MSVC 1800")
endif()
if("${CMAKE_GENERATOR}" STREQUAL "Visual Studio 9 2008")
message("Toolchain: MSVC 1500")
endif()

Whats the proper way to link Boost with CMake and Visual Studio in Windows?

I am trying to generate some Boost 1.58 libraries that I need (chrono, regex and thread) for Visual Studio 2012 and link the libraries with CMake. I have real problems for CMake and Visual Studio to find or link the libs, depending on the configuration I set.
I am finally using the following configuration:
bjam.exe --link=static --threading multi --variant=debug stage
But this doesn't seem to generate static libs.
How should I generate the libs and search them with CMake in order for Visual Studio to link them properly?
I finally came up with the solution and I think it is detailed enough to become a generic answer.
Visual Studio searches for dynamic libraries so we need to compile Boost libraries as shared, multithreaded, debug and release, and runtime-link shared. In windows using bjam.exe all commands have the prefix "--" except link, so the right way to build the libraries is:
bjam.exe link=shared --threading=multi --variant=debug --variant=release --with-chrono --with-regex --with-thread stage
This will generate the libs and DLLs in the folder Boost/stage/lib, so we need to set an environment variable Boost_LIBRARY_DIR C:/Boost/stage/lib, for example.
There are more options that may come in hand:
runtime-link = shared/static
toolset= msvc-11.0
The libraries will have a name like this for release:
boost_chrono-vc110-mt-1_58.lib
boost_chrono-vc110-mt-1_58.dll
And for debug:
boost_chrono-vc110-mt-gd-1_58.lib
boost_chrono-vc110-mt-gd-1_58.dll
In order for CMake to link them properly we need to write the following in the CMakeLists.txt:
add_definitions( -DBOOST_ALL_DYN_LINK ) //If not VS will give linking errors of redefinitions
set(Boost_USE_STATIC_LIBS OFF )
set(Boost_USE_MULTITHREADED ON)
set(Boost_USE_STATIC_RUNTIME OFF)
find_package(Boost COMPONENTS thread chrono regex REQUIRED )
INCLUDE_DIRECTORIES(${Boost_INCLUDE_DIRS})
TARGET_LINK_LIBRARIES( ${PROJ_NAME} ${Boost_LIBRARIES} )
bjam.exe --link=static --threading multi --variant=debug stage
But this doesn't seem to generate static libs.
Building the special stage target places Boost library binaries in the stage\lib\ subdirectory of the Boost tree.
More about building Boost on Windows here
CMake:
SET (CMAKE_BUILD_TYPE Debug) # in order to link with boost debug libs you may need to set that to build your program in debug mode (or do that from command line)
FIND_PACKAGE (Boost 1.58 COMPONENTS "chrono" "regex" "thread" REQUIRED)
#ADD_DEFINITIONS(-DBOOST_ALL_DYN_LINK) # make sure you don't have this as it will try to link with boost .dll's
INCLUDE_DIRECTORIES(${Boost_INCLUDE_DIRS})
LINK_DIRECTORIES(${Boost_LIBRARY_DIRS})
TARGET_LINK_LIBRARIES(${EXE_OR_LIB_NAME} ${Boost_LIBRARIES})

CMake - compile with /MT instead of /MD

I'm a newbie to cmake (2.8.12.1) and I'm using it on Windows to generate the project files to build cpp-netlib using Visual Studio 2012.
By default it compiles with the /MDd compiler switch. I want to change it so that it uses /MTd.
I followed the advice given here https://stackoverflow.com/a/14172871 but it isn't working for me.
Specifically, I added the second line shown below in the if statement to CmakeLists.txt.
if (MSVC)
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} /bigobj")
set(CMAKE_CXX_FLAGS_DEBUG "${CMAKE_CXX_FLAGS_DEBUG} /MTd")
endif()
When I open the Visual Studio sln file I can see that the /MDd option is still set. Furthermore, I see the following in CMakeCache.txt:
//Flags used by the compiler during debug builds.
CMAKE_CXX_FLAGS_DEBUG:STRING=/D_DEBUG /MDd /Zi /Ob0 /Od /RTC1
I've also tried setting the flags from scratch like this:
set(CMAKE_CXX_FLAGS_DEBUG "/MTd")
but that doesn't work either.
If I pass the option via the command line like this:
-DCMAKE_CXX_FLAGS_DEBUG="/MTd"
the option is successfully set in the Visual Studio projects.
Can anyone tell me what I'm doing wrong?
I would also appreciate it if someone could enlighten me as to where the values in the cache come from that I don't specify on the command line or aren't in CmakeLists.txt.
Adding CMakeList.txt as requested. I've never posted before so apologies if I've not done this right.
# Original from cpp-netlib.org with my edits
cmake_minimum_required(VERSION 2.8)
project(CPP-NETLIB)
set(Boost_USE_STATIC_LIBS ON)
set(Boost_USE_MULTI_THREADED ON)
find_package( Boost 1.45.0 REQUIRED unit_test_framework system regex date_time thread filesystem program_options chrono )
find_package( OpenSSL )
find_package( Threads )
set(CMAKE_VERBOSE_MAKEFILE true)
if (CMAKE_BUILD_TYPE MATCHES Debug)
add_definitions(-DBOOST_NETWORK_DEBUG)
endif()
if (OPENSSL_FOUND)
add_definitions(-DBOOST_NETWORK_ENABLE_HTTPS)
include_directories(${OPENSSL_INCLUDE_DIR})
endif()
if (${CMAKE_CXX_COMPILER_ID} MATCHES GNU)
set (CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wall")
endif()
if (Boost_FOUND)
################# added #################
add_definitions(-DBOOST_ALL_NO_LIB)
#########################################
if (MSVC)
add_definitions(-D_SCL_SECURE_NO_WARNINGS)
endif(MSVC)
if (WIN32)
add_definitions(-D_WIN32_WINNT=0x0501)
endif(WIN32)
include_directories(${Boost_INCLUDE_DIRS})
enable_testing()
add_subdirectory(libs/network/src)
add_subdirectory(libs/network/test)
if (NOT MSVC)
add_subdirectory(libs/mime/test)
endif(NOT MSVC)
add_subdirectory(libs/network/example)
endif(Boost_FOUND)
if (MSVC)
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} /bigobj")
################# added #################
set(CMAKE_CXX_FLAGS_DEBUG "${CMAKE_CXX_FLAGS_DEBUG} /MTd")
#########################################
endif()
enable_testing()
Adding the code inside your if block should work fine. However, since it doesn't produce the required effect in your .sln, either the code inside the if block isn't being executed or the flags are being replaced later in the CMakeLists.txt.
As to where the cached values for these flags come from; CMake applies and caches what are considered to be useful default values for each default build type.
Have you added your changes to the flags before the project call? project sets up a lot of things, including the compiler flags. If you set these flags without caching them (i.e. calling set as you have shown), project will overwrite them. If you set the flags and cache them (e.g. using set(... CACHE), or by adding them via the command line arg -D as you have shown), then project won't overwrite them.
Also, since calling set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} /bigobj") doesn't use the CACHE option of set, then this change to the variable CMAKE_CXX_FLAGS won't appear in your CMakeCache.txt file.
In order to get this into the cache, you'd have to also use the FORCE option of set, since you'd be telling CMake to replace an already-cached value (CMake itself caches these flag variables by default). I wouldn't recommend this however - I can't see why you'd need to do this, and you'd be best to look for a better way than appending the flag(s) you want, since every time CMake runs the appended flags would be re-appended.
If this doesn't allow you to resolve your issue, perhaps you could show a full (small) CMakeLists.txt which exhibits the problem?
UPDATE:
OK - The problem is a scoping issue. The changes to the compiler flags will be applied to all targets (exes/libs) which are defined in that CMakeLists.txt, but only to subdirectory targets which are added after the flags are modified.
The add_subdirectory command introduces a new scope (although this isn't mentioned in the docs) which inherits a copy of the parent's variables. However, subsequent changes to the variables in the parent scope don't affect the child copies, and likewise changing the child copies doesn't affect the value of the parent's copies (unless you force it using set(... PARENT_SCOPE)).
So, to fix your issue, just move the if(MSVC) block to before all the add_subdirectory calls.

pragma and including headers/libraries

VS C++ 2008
I am just working through a DirectX tutorial.
In the source code had this line:
#pragma comment (lib, "d3d9.lib")
When I compiled everything linked ok.
However, I commented out this line and tried to include the header and library myself under properties, like this:
C/C++ - General
Additional include directories: "C:\Program Files\Microsoft DirectX SDK (August 2009)\Include"
Linker - General
Additional library directories: "C:\Program Files\Microsoft DirectX SDK (August 2009)\Lib\x64"
Linker - Input: d3d9.lib
However, I got this linker error:
1>main.obj : error LNK2019: unresolved external symbol _Direct3DCreate9#4 referenced in function _initD3D
However, when I just use the pragma I didn't get any linker errors. Only when I try and include them with the properties as above.
What is the real difference in using pragma and including the header/libraries using the properites?
Many thanks,
at first, #pragma comment(lib) is just linker configuration
at second, the SDK should be in path, so dont set additional library directories (you may override it with wrong version), just add d3d9.lib to linker's input.
As far as I know, there is no difference. pragma lib simply says to the linker to look for a specific library by name.
Also, since the path is not specified in the pragma, the linker relies on the current lib paths for your project. Try not add any path to your linker options (by default DX SDK adds paths to any visual studio installed, directly modifying the global visual studio paths. See Tools/Options/Projects and Solutions/VC++ Directories/Show Directories for Library files)
Some things to check:
you are indeed building for x64
your path is really pointing to the DX SDK (it is installed to Program Files(x86) if you are on x64)
verify if there are not other linker warnings

Resources