Setting custom include path for FetchContent?

By default, FetchContent seems to add the toplevel directory of the fetched code to the include path. Is there any way to customize this, so that fetched source that is out of your control can be segregated to avoid possible filename collision? What I’d like to be able to do is have all my fetched content under “third_party/LIBNAME/…”, so that all the #includes in my source make it clear and obvious that the fetched stuff is, well, fetched.

1 Like

The include path that you can use in source code depends on the project you are fetching. If the project has folder structure eg. /proj/super-app/include/super/feature.hpp then if the include directory for the target is set to folder include then you can access it via folder super. You can set the include folder via target_include_directories(...).

#include <super/feature.hpp>

However if you meant that you want all your code to certain path you decide, third_party (or external) for example, then you can set it with variable FETCHCONTENT_BASE_DIR.


This has the benefit that you can keep the dependencies even if you would delete the build folder completely.
However I don’t know the exact answer to your problem. The documentation tell us this:

FetchContent_Populate( <name>
  [SUBBUILD_DIR <subBuildDir>]
  [SOURCE_DIR <srcDir>]
  [BINARY_DIR <binDir>]

"SOURCE_DIR defaults to ${CMAKE_CURRENT_BINARY_DIR}/<lcName>-src and BINARY_DIR defaults to ${CMAKE_CURRENT_BINARY_DIR}/<lcName>-build ."

Maybe those variables can help you set the right folders.

FetchContent does not add anything to the header search path. Most likely it is the project being added that is itself adding that header search path. If a project is unilaterally adding CMAKE_SOURCE_DIR instead of CMAKE_PROJECT_SOURCE_DIR or CMAKE_CURRENT_SOURCE_DIR as a header search path (or just about any other use for that matter), then you need to work with that project and suggest they make that change. Some projects were not originally written to expect to be incorporated into another build via add_subdirectory() and this is one of the more common problems that are a symptom of that. The fixes are usually easy, but require the cooperation of the project maintainer.