Suppose I want to create a library which using Boost:

find_package(Boost 1.46.1 REQUIRED COMPONENTS filesystem system)
add_library(hello_library SHARED src/Hello.cpp)
target_include_directories(hello_library PUBLIC ${PROJECT_SOURCE_DIR}/include)
target_link_libraries(hello_library PRIVATE Boost::filesystem)

May I ask what is the difference between target_link_libraries(hello_library PRIVATE Boost::filesystem) and target_link_libraries(hello_library PUBLIC Boost::filesystem) ?

I suggest to update the default type section.

Instead of redefining the CMAKE_BUILD_TYPE variable, we can change the value using the associated property as follows

if(NOT CMAKE_BUILD_TYPE AND NOT CMAKE_CONFIGURATION_TYPES)
  set_property(CACHE CMAKE_BUILD_TYPE PROPERTY VALUE Release)
endif(NOT CMAKE_BUILD_TYPE AND NOT CMAKE_CONFIGURATION_TYPES)

If one wishes to restrict choices to standard build types, it gives

if(NOT CMAKE_BUILD_TYPE AND NOT CMAKE_CONFIGURATION_TYPES)
  set_property(CACHE CMAKE_BUILD_TYPE PROPERTY STRINGS None Debug Release RelWithDebInfo MinSizeRel)
  set_property(CACHE CMAKE_BUILD_TYPE PROPERTY VALUE Release)
endif(NOT CMAKE_BUILD_TYPE AND NOT CMAKE_CONFIGURATION_TYPES)

It would be useful if there would be an example that includes multiple directory levels. Example:

├── CMakeLists.txt
└── subfolder
    └── CMakeLists.txt
    └── subfolder1
    │  └── CMakeLists.txt
    └── subfolder2
       └── CMakeLists.txt

I had a situation like that and manage to solve it. It would be nice to have a similar example (I did not manage to find one at least).

The examples are extremely practical and helpful, so I'll be referring a lot of people to this repository.

I think there are some conventions around unit test folders and files. If you could show some examples of how that would look with any unit test framework I think it would be sensible addition. Also, leveraging them with CTest would make sense if possible.

Current best practices in CMake are to define each target's include, link, and compile definitions on the target itself, using appropriate PRIVATE, PUBLIC, and INTERFACE annotations to define target usage requirements. This avoids issues caused by using 'global' configuration and enables automatic, transitive propagation of usage requirements.

This does depend on updates made in recent versions of CMake. I believe 2.8 is the earliest to support this, with further improvements in 3.x versions.

First of all, thank you for this helpful tutorial.

In my understanding, the intent of chapter H was to show linking using Non-alias targets. Imported alias targets was rather used in chapter K, so it seems the content is duplicated.

Hey there, I was going through the examples to learn about cmake & i saw that for shared library examples if we are building the executable it will show following D:\Study\compiler\software\src\Hello.cpp(3): fatal error C1083: Cannot open include file: 'shared/Hello.h': No such fil e or directory [D:\Study\compiler\software\build\hello_library.vcxproj]

Big thanks for this project, it really helped me learn CMake! When going through the tutorial, I noticed a number of minor misspellings. Using codespell, I was able to find and fix a number of other spelling errors.

Some libraries like GLFW provide a global include file or files.

Taking the folder structure from the 01-basic/C-static-library as a base, it would work like this:

$ tree
.
├── CMakeLists.txt
├── include
│   └── static
│       └── MyLib.h
└── src
    ├── Hello.h
    ├── Hello.cpp
    └── main.cpp

Now all headers could live inside the source directory and a single MyLib.h header could be provided for library users, with the definitions of everything that should be exposed.

This would be useful for writing internal classes that are not exposed to the library users, concentrating utilities in the "global header" (like GLFW does here, for example) while also providing library users with a single include file.

I have been trying to do this myself, but the problem I'm facing is getting the MyLib.h file to resolve includes of files inside the src folder. Given a few nudges in the right direction, I'd gladly submit a working example as a PR if this was to be considered a valid example.

Hi,

In your example "cmake-examples/01-basic/D-shared-library/", what happens when we call main? Where does it look for the library? Can we define it somehow? When we package the software, is putting the library in the same folder as main enough?

Thank you for the examples,

Hi ttroy50, thanks for the tutorial, it has helped me very much. Well done! My personal project has a similar tree structure as your cmake-examples/02-sub-projects/A-basic/ with a couple of libraries and an app directory. The libraries I build with cmake 3.10.2 & make work very well, like yours do. However, my app binary does not. I have worked and worked on this... which is how I found my way to your ttroy50/cmake-examples.

The reason I am writing is because my error turns out to be the same as the cmake & make errors I encounter in your cmake-examples/02-sub-projects/A-basic/subbinary/CMakeLists.txt. Which is 'Target "subbinary" links to target "sub::lib1" but the target was not found. Perhaps a find_package() call is missing for an IMPORTED target, or an ALIAS target is missing?' etc etc

I was wondering if your /subbinary/CMakeLists.txt could be adjusted to clear these errors allowing it to generate a functional make on it. If so, I suspect it will teach me how to fix my own equivalent build problem.

Thanks and best regards from Rio del Mar, California. Billy

Hello, nice work creating/collecting all the examples.

I used your project to integrate clang-format into CMake. Doing that I adapted it slightly and want to suggest this as a possible improvement. I found that the check target would just error if code was not formatted. In clang-format you can use the --dry--run and --Werror flags to get output of what was not formatted and also getting a sensible return code without grep. My code for the custom target looks like this:

add_custom_target(clang-format-check
        COMMENT "Checking clang-format changes"
        COMMAND ${ClangFormat_EXECUTABLE}
        --style=file
        --dry-run
        --Werror
        ${ALL_SOURCE_FILES}
        )

The output when run:

i found some unnormal prints in this example. check it please.

# A CMake script to find all source files and setup clang-format targets for them

# Find all source files
set(CLANG_FORMAT_CXX_FILE_EXTENSIONS ${CLANG_FORMAT_CXX_FILE_EXTENSIONS} *.cpp *.h *.cxx *.hxx *.hpp *.cc *.ipp)
file(GLOB_RECURSE ALL_SOURCE_FILES ${CLANG_FORMAT_CXX_FILE_EXTENSIONS})

# Don't include some common build folders
set(CLANG_FORMAT_EXCLUDE_PATTERNS ${CLANG_FORMAT_EXCLUDE_PATTERNS} "/CMakeFiles/" "cmake")

# get all project files file
foreach (SOURCE_FILE ${ALL_SOURCE_FILES})
    foreach (EXCLUDE_PATTERN ${CLANG_FORMAT_EXCLUDE_PATTERNS})
        string(FIND ${SOURCE_FILE} ${EXCLUDE_PATTERN} EXCLUDE_FOUND) 
        if (NOT ${EXCLUDE_FOUND} EQUAL -1) 
            list(REMOVE_ITEM ALL_SOURCE_FILES ${SOURCE_FILE})
        endif () 
    endforeach ()
endforeach ()

message(STATUS "ALL_SOURCE_FILES: ${ALL_SOURCE_FILES}")     # ${ALL_SOURCE_FILES} is empty

in https://github.com/ttroy50/cmake-examples/tree/master/01-basic/G-compile-flags: the picture link(https://github.com/ttroy50/cmake-examples/blob/master/01-basic/G-compile-flags/cmake-gui-set-cxx-flag.png) is not available