This repository showcases a form of vendoring. Vendoring is a bad practice of pulling in source code of other projects into your own and building those projects in the same build as your own. This makes packaging a project potentially very difficult or otherwise requires unnecessary patches to be maintained by the package manager that remove the vendoring.
You can't realistically vendor any project. They must be architected in a way that allows them to be consumed like this. The dependency that is used as an example in this repository was generated by cmake-init, which produces projects that are by default easy to vendor.
Even if something is easy to vendor, because everything happens in a single build, the vendored project will inherit your flags, which could cause errors in sources compiled from the vendored project if you are using a warnings-as-errors flag.
This project was generated by cmake-init.
It's heavily stripped down to focus on showing how to optionally make
dependencies available using FetchContent via find modules.
If you look at the build script, you will see that the
dependency is imported using the find_package command like normal. This is
very important! The point of this example is to showcase vendoring that is
done completely transparently.
You will also notice that the linking is done using the
target that contains a double colon. If you were using an IMPORTED target
that was created by a CMake package's config file, then you would have the
exact same target name. The target name in this case comes from the ALIAS
target from the dependency's build script.
The opt-in is done by setting the CMAKE_MODULE_PATH variable in the dev
preset, which enables the find_package command to
find the Findheaderonly.cmake file in
module mode. We know that find_package will use module mode first before
config mode, because the basic signature of the command is used and
CMAKE_FIND_PACKAGE_PREFER_CONFIG isn't enabled.
The rest of the logic is explained in the find module.