c++ - How to have CMake show headers-that are not part of any binary target-in the IDE?

Question

In our workflow, we can have a module A that is composed of several header files, module A not producing any binary (side note: it will obviously be used by other modules, that include some of the headers from module A to produce binaries).

A good example would be a header-only library, for which CMake 3 introduces a good support thanks to the notion of INTERFACE library (see this SO answer, and CMake's documentation of the feature).

We can make an interface library target out of module A:

add_library(module_A INTERFACE)

That gives us all the nice features of CMakes targets (it is possible to use it as another target's dependency, to export it, to transitively forward requirements etc.)

But in this case, the headers in module A do not show up in our IDE (Xcode, yet we expect it to be the same with most/every other IDE).

This proves to be a major drawback in the workflow, since we need the files composing module A to be shown in the IDE for edition. Is it possible to achieve that ?

question from:https://stackoverflow.com/questions/27039019/how-to-have-cmake-show-headers-that-are-not-part-of-any-binary-target-in-the-ide

Answer 1

Several months down the line, I did not find a way to directly list the header files for an INTERFACE library.

Since the question still has some views, here is what I ended up doing (i.e. what appears like the lesser hack currently available).

Imagine module A is a header only library. In the CMakeLists.txt declaring its target:

# Define 'modA_headers' variable to list all the header files
set(modA_headers 
  utility.h
  moreUtilities.h
  ...)

add_library(moduleA INTERFACE) # 'moduleA' is an INTERFACE pseudo target

#
# From here, the target 'moduleA' can be customised
#
target_include_directories(moduleA ...) # Transitively forwarded
install(TARGETS moduleA ...)

#
#  HACK: have the files showing in the IDE, under the name 'moduleA_ide'
#
add_custom_target(moduleA_ide SOURCES ${modA_headers})

I do not accept this answer, since I expect further releases of CMake to offer a more semantically correct approach, which will then be accepted : )