On target_include_directories (${CMAKE_CURRENT_LIST_DIR})

Usage
1

It’s been a few days since I cmake’d (cmade? cmooked?) and I find myself utterly confused as to why I can’t include “Lib.h” from target “Lib” which even has “Lib.h” listed as one of its sources, without explicitly adding Lib’s directory to its include paths.

This has been a continual source of misunderstandings from the users I support who without fail have defaulted to assuming that if you link a library you can see its includes, and when that doesn’t work, they start pouring relative paths with "…"s and all into the system.

A few weeks diversion into Python and I finally fell for it too. Now, suggesting this line to one of my coworkers makes zero sense to me:

target_include_directories (Lib PUBLIC ${CMAKE_CURRENT_LIST_DIR})

Specifically - changing the include paths of Lib feels egregious since it was already able to include the headers. But

target_include_directories (Lib INTERFACE ${CMAKE_CURRENT_LIST_DIR})

introduces more questions than it answers.

TLDR Is there a manner of saying “and MY include files” that is more explicit than idiom?

Or is

add_library (Lib Lib.cpp Lib.h)
target_include_directories (Lib INTERFACE ${CMAKE_CURRENT_LIST_DIR})

The Way?

I think I understand why libraries don’t automatically pollute with their local directory as an include path, but it seems like something as ought to be obviously surfaced with a parameter.

-Oliver

2

Yes. Use file sets to let CMake know about your header structure. It’s a bit more verbose, but it means CMake can help create the correct include paths automatically.

target_sources(Lib
  PUBLIC
    FILE_SET HEADERS FILES Lib.h)