I hope this overview helps! Feel free to ask if you have any further questions. Using properties not supported by your compiler will also cause issues.Incorrect property names or values will lead to build errors.Use set_property(SOURCE) for setting properties globally.Use get_source_file_property() to retrieve a property value.You can find a list in the CMake documentation. Available properties depend on your compiler and build system.Properties are only visible to targets in the same directory or specified using DIRECTORY or TARGET_DIRECTORY.Finally, it creates an executable using these sources and headers. This example sets the language property for header files and sets optimization and linking flags for source files. Source1.cpp source2.cpp PROPERTIES COMPILE_FLAGS '-O3'Īdd_executable(my_program source1.cpp source2.cpp header1.h header2.h) Header1.h header2.h PROPERTIES LANGUAGE CXX) Here's a more complete example demonstrating property usage: set_source_files_properties( This example sets the COMPILE_FLAGS property for main.cpp and my_library.cpp to '-Wall -g', enabling warnings and debugging information.

PROPERTIES: A key-value list where the key is the property name and the value is its desired setting.Įxample: set_source_files_properties(main.cpp my_library.cpp PROPERTIES COMPILE_FLAGS '-Wall -g').

TARGET_DIRECTORY: Optionally specify the directory of targets these properties apply to.

DIRECTORY: Optionally specify the directory where the files reside.

These properties influence how the compiler treats those files during the build process. Sometimes you need them, but be careful.Set_source_files_properties() is a CMake command that allows you to set specific properties for source files in your project. Which can make life easier for consumers of your library.Īpplying pre-processor flags (Or any compiler flag) globally can create hidden dependencies in your build.Įssentially think of add_compile_definitions as globals in C/C++. Allows usage of PRIVATE/PUBLIC/INTERFACE if needed.It's much more clear to readers of your CMake code how it works.Why is target_compile_definitions better/preferred? Due to not being modular, not scaling well, not supporting generator expressions, etc. These approaches really aren't recommended anymore. Otherwise if users consume your library using add_subdirectory they may have issues. If you use this approach be careful if you are the top level project. add_compile_definitions(WIN32_LEAN_AND_MEAN NOMINMAX) Here is the same logic as above with add_compile_definitions. # Prevents Windows.h from defining min/max as macrosįind more explanation on which commands to use for compiler flags here: Īdd_compile_definitions applies macros to any targets that are defined after the call. # Prevents Windows.h from adding unnecessary includes Target_compile_definitions(my_lib PRIVATE IE the macro will only be added to your exe/library. The reason you should prefer this approach over any other approach is because it granularity is target based. If you are using CMake 3.X your first choice for adding a preprocessor macro should be target_compile_definitions. The more modern command, add_compile_definitions(), was not added until CMake 3.12.' PLEASE NOTE (as suggests in one of the comment): 'if you are using CMake 3.3.2, you have to use add_definitions() or target_compile_definitions(). The line is so modified: add_definitions(-Dfoo=5) # <-HERE THE NEW CMAKE LINE inside CMakeLists.txt I needed to use: add_definitions(-Dfoo) # <-HERE THE NEW CMAKE LINE inside CMakeLists.txtĪnd, in order to have a preprocessor macro definition like this other one: #define foo=5 With CMake version 3.3.2, in order to create #define foo The cmake documentation can be found on the official page. Check the version of your Cmake by using $ cmake -version and pick the solution that fits your needs. Here the solution for the version I am using (i.e., 3.3.2). The other solutions proposed on this page are useful for some versions of Cmake > 3.3.2.

Cmake set source