I am new to CMake, and I want to set _ITERATOR_DEBUG_LEVEL to 0 for Release build, and 2 for Debug build, to fix issues when trying to compile a project that depends on other projects.
Error:
_iterator_debug_level value '2' doesn't match value '0' (this is for Release Win32 build, where the main project has the value disabled(0) and the project that it is dependent on has it enabled for some reason, somewhere)
I do not have a C/C++ properties section in the main project since it is a Utility project that depends heavily on CMake. Hence I need to fix this through CMake options only.
Can anyone point me to the way of setting visual studio option via CMake?
add_definitions(-D_ITERATOR_DEBUG_LEVEL=0)
in CMakeLists.txt seems to work
add_definitions is deprecated. Use add_compile_definitions to specify the iterator debug level in CMakeLists.txt.
add_compile_definitions($<$<CONFIG:Debug>:_ITERATOR_DEBUG_LEVEL=1>)
Related
We have a C++ CMAKE project. I work on it under Windows using Visual Studio 2019. My coworkers work under Ubuntu using QTCreator.
Here is what my current steps look like for swapping from a DEBUG build to a RELEASE build:
First set up VTK:
Open the release VTK build folder in Visual Studio and build the "INSTALL" subproject to overwrite the installed debug version of VTK with the release build.
Then set up our project:
Edit my account's PATH environment variable to point to the location of the new sub-project DLLs where Visual Studio will put them. (myProject\lib\analytics\Debug to myProject\lib\analytics\Release)
Without telling Windows where the sub-project's DLLs are, trying to execute the program does not work. Not sure if there's a way to tell Visual Studio to look for the DLLs automatically.
Edit the top-level CMAKE of the project:
SET(BUILD_MODE Release)
set(CMAKE_BUILD_TYPE "RELEASE" CACHE STRING "Sets release build by default")
Open Cmake-GUI and clear the cache, then run "Configure" and "Generate"
If I do not clear the cache, Cmake Gui has consistently used older/incorrect settings resulting in unusual build issues.
Open the project under Visual Studio, changing the build type at the top to my new choice.
Hit "Rebuild" on ALL_BUILD.
With all those steps done, I have managed to swap from a Debug to a Release build.
Is there some way to simplify this process and make it easier to swap between the two?
I am not very familiar with Visual Studio or Cmake, so I'm not sure what functionality I'm missing out on.
There should be no need to change reconfigure the cmake, project when using a multi configuration generator. This of course assumes that the VTK package provides imported targets via find_packag(VTK) that properly work with different configurations. You should be able to verify this by checking the import libraries for different configurations of one of your targets in Visual Studio: there are different import libs for the Release and Debug configurations, you're good to go.
As for enabling your program to find the dlls depending on the confiruation, when using the "Play Button" (Visual Studio Debugger):
You should be able to use generator expressions to modify PATH variable in the environment depending on the configuration.
The following assumes the dlls are located in .../lib/<vtk_component_name>/(Debug|Release) directories.
# should evaluate to "C:/Users/..../buildarea/.../lib"
# Note: it's very likely find_package(VTK) already provides necessary info
set(VTK_BASE_DIR "...")
set(VTK_PATH "")
foreach(VTK_COMPONENT IN ITEMS
data-manager
execution
...
)
# use vtk Release configuration for everything but the debug config
set(VTK_PATH "${VTK_BASE_DIR}/${VTK_COMPONENT }/$<IF:$<CONFIG:Debug>,Debug,Release>;${VTK_PATH}")
endforeach()
set_target_properties(my_exe PROPERTIES
VS_DEBUGGER_ENVIRONMENT "PATH=${VTK_PATH}$ENV{PATH}"
)
I've just moved over a Visual Studio (C++) solution over to another computer, setup all the directories and settings as far as I can see, and did a clean/rebuild on the solution. I get the error above on a bunch of .obj's on compile, not sure what to do about it.
It seems that you are mixing object files built with different settings. Try to do a full clean rebuild and check all project file settings to make sure that the _ITERATOR_DEBUG_LEVEL macro is the same (e.g., you are not mixing debug and release built objects).
In some cases, mixing the options in
Properties>Configuration Properties>C/C++>Code Generation>Runtime
Library
Between included Library(ies) and currently working project
can cause this problem.
Depending on usage set it as /MD or /MT or /MDd or /MTd uniformly across all projects.
Mixing binaries (object files) is one reason; another (which I encountered) is the false definition of the _DEBUG macro in the release build. _DEBUG is not a standard macro, but used by Microsoft.
After editing the .vcxproj-file in Emacs I mistyped _DEBUG instead of NDEBUG for the release, and encountered precisely the same build error.
I have been trying to solve this issue for five days. The Point Cloud Library (PCL) code builds successfully in debug mode but fails in release mode.
I have reconfigured my library several times but it didn't help. I found the problem was that the release version was inheriting _DEBUG so I unchecked it under project properties >> Preprocessor >> Processor Definitions and it was solved.
I found out (oddly) that _CRT_NON_CONFORMING_SWPRINTFS causes it. When I remove it, I don't get "_iterator_debug_level value '0' doesn't match value '2'" but instead the following warning:
Error 6 error C4996: '_swprintf': swprintf has been changed to conform with the ISO C standard, adding an extra character count parameter. To use traditional Microsoft swprintf, set _CRT_NON_CONFORMING_SWPRINTFS.
After trying to solve issue for several days in a debug version of my VS2019 project. Setting the Project >> Properties >> C/C++ >> Processor _HAS_ITERATOR_DEBUGGING=0 definition worked for me.
In my particular case, I encountered this error when using Conan with CMake while following their tutorial. When I generated the Visual Studio project, it built fine in Release mode but threw this error in Debug mode.
The solution was to generate a separate Visual Studio project with Debug libraries:
mkdir debug && cd debug
conan install --build=missing .. -s build_type=Debug
cmake ..
Can repeat the same in Release mode: change directory in line #1 and in line #2 use any one of ['None', 'Debug', 'Release', 'RelWithDebInfo', 'MinSizeRel']
I have a VS2008 solution in which there is a C++ project (we'll name it Project1 for clarity's sake). The project's purpose is to test the executable generated by the compilation of another C++ project (Project2) in the same solution. The executable being tested (Project2.exe) is built in the same folder than the executable generated by our Project1 (Project1.exe). Here's what is looks like in the build folder:
Build_path/Debug
Project1_Debug.exe
Project2_Debug.exe
Build_path/Release
Project1.exe
Project2.exe
The project Project1 is set in the Configuration Manager to always build in debug (even when the solution build in release), since there is a problem with one of the third party tool used in Project1 when we compile in release. So any preprocessor definitions that would identify Project1's configuration would always be set to debug. Knowing this and the fact that Project2 build in release when the Solution Configuration is set to build in release, how can project1 locate project2 when building the solution in release, since it always search in the same folder it is located in?
Constraint(s):
I cannot change the build folder structure
As mentioned, using Project1's preprocessor definitions with a macro such as $(Configuration) won't help here, since $(Configuration) would be bound to Project1's configuration and would always be set to debug.
I am using GetModuleFileName to fetch Project1's executable and from that location (which is always in the debug folder), the only solution I found was to search for a macro representing the current solution configuration, which would help me to fetch Project2.exe in the release folder when building my solution in release (but Project1 still in debug) by adding ../Release in my path and stay in the debug folder when Project2 is actually in the debug folder (when the solution is built in debug) by adding ../Debug in my path.
A little pseudo-code would look like this:
If SOLUTION_CONFIGURATION == DEBUG // Project 1 and Project2 is in debug folder
add ../Debug in my research path to locate Project2_Debug.exe from Project1_Debug.exe's location
Else if SOLUTION_CONFIGURATION == RELEASE // Project1 is in debug and Project2 is in release folder
add ../Release in my research path to locate Project2.exe from Project1_Debug.exe's location
End if
There are no standardard macros for representing configurations and version information.
However, MS maintains a list of predefined macros for Visual Studio.
Some may be available with other compilers.
P.S. I found the site by searching the internet using the keywords "Visual Studio predefined macros".
I have tried to setup and create wxWidgets project using wxWindgets installer and code::block-mingw installations.
When I am trying to create a wx-widgets smith project, I have below problem
A matching Debug configuration cannot be found in the wxWidgets directory you specified.
This means Debug target of your project will not build
Are you sure you want to continue with these settings ?
does anybody have any idea about this and what is the recommended way to setup wxWidgets and code-block in Windows ?
Did you compile your wxWidgets as a debug build? I got the same error, because I only buitl wxWidgets as a release build. However, I didn't intend to use the debug build anyway, because I didn't want to debug it, just use it. So you can continue with your project and then you have to replace the library names with the correct ones. Mostly this means removing the d at the end of the library name.
If you want to use a debug build, you have to build wxWidgets as a debug as well.
To fix the library names, you'd have to right-click on your project and go to "Build options... -> Linker settings".
Update
To compile it using MingW you have to follow this guide.
You may also have to adjust the include paths in your build options:
D:\src\c\wxWidgets_3.0.0\lib\gcc_lib\msw
D:\src\c\wxWidgets_3.0.0\include
And for the linker:
D:\src\c\wxWidgets_3.0.0\lib\gcc_lib
Problem is solved by following the exact instruction provided in Compiling wxWidgets 3.0.0 to develop Code::Blocks (MSW) section. I couldn't build wxWidgets correctly in windows. After I build wxWidget the same alert message mentioned in the question was popped when creating wxWidgets project using Code::Block but I dismissed and continue to create the project. This time it was worked.
I've just moved over a Visual Studio (C++) solution over to another computer, setup all the directories and settings as far as I can see, and did a clean/rebuild on the solution. I get the error above on a bunch of .obj's on compile, not sure what to do about it.
It seems that you are mixing object files built with different settings. Try to do a full clean rebuild and check all project file settings to make sure that the _ITERATOR_DEBUG_LEVEL macro is the same (e.g., you are not mixing debug and release built objects).
In some cases, mixing the options in
Properties>Configuration Properties>C/C++>Code Generation>Runtime
Library
Between included Library(ies) and currently working project
can cause this problem.
Depending on usage set it as /MD or /MT or /MDd or /MTd uniformly across all projects.
Mixing binaries (object files) is one reason; another (which I encountered) is the false definition of the _DEBUG macro in the release build. _DEBUG is not a standard macro, but used by Microsoft.
After editing the .vcxproj-file in Emacs I mistyped _DEBUG instead of NDEBUG for the release, and encountered precisely the same build error.
I have been trying to solve this issue for five days. The Point Cloud Library (PCL) code builds successfully in debug mode but fails in release mode.
I have reconfigured my library several times but it didn't help. I found the problem was that the release version was inheriting _DEBUG so I unchecked it under project properties >> Preprocessor >> Processor Definitions and it was solved.
I found out (oddly) that _CRT_NON_CONFORMING_SWPRINTFS causes it. When I remove it, I don't get "_iterator_debug_level value '0' doesn't match value '2'" but instead the following warning:
Error 6 error C4996: '_swprintf': swprintf has been changed to conform with the ISO C standard, adding an extra character count parameter. To use traditional Microsoft swprintf, set _CRT_NON_CONFORMING_SWPRINTFS.
After trying to solve issue for several days in a debug version of my VS2019 project. Setting the Project >> Properties >> C/C++ >> Processor _HAS_ITERATOR_DEBUGGING=0 definition worked for me.
In my particular case, I encountered this error when using Conan with CMake while following their tutorial. When I generated the Visual Studio project, it built fine in Release mode but threw this error in Debug mode.
The solution was to generate a separate Visual Studio project with Debug libraries:
mkdir debug && cd debug
conan install --build=missing .. -s build_type=Debug
cmake ..
Can repeat the same in Release mode: change directory in line #1 and in line #2 use any one of ['None', 'Debug', 'Release', 'RelWithDebInfo', 'MinSizeRel']