In CLion, header only library: file "does not belong to any project target, code insight features might not work properly"

Question

I have a header-only library project set up with the cmake command:

add_library(my_library INTERFACE)

and I also added

target_sources(my_library INTERFACE ${MY_LIRBARY_HEADER_FILES})

but when I open a source file, I get the warning:

This file does not belong to any project target, code insight features might not work properly

and I lose a lot of the functionality on things like code completion.

What is the proper way to set this up so CLion provides its usual functionality on a header-only library?

Solution 1

Little background

I was having the same problem, albeit the project was not header-only, nevertheless, the open files from inc folder were throwing the aforementioned warning, even though the CMake file clearly marked that folder to be include_directory.

*.hpp files do not belong to ${SOURCE}

include_directories("${PROJECT_SOURCE_DIR}/inc/")
add_subdirectory(src)
add_executable(${EXECUTABLE_NAME} main.cpp ${SOURCE})

Since this is a perfectly valid CMake file and adding the include files to source files is not idiomatic, I did not want to amend the CMake file.

The solution

As described on the official JetBrains Forum, the CMake file is indeed valid and the warning is shown because of the inability of CLion to properly index header files. The suggested workaround extracted from the link is to right-click the folder and Mark directory as | Library Files/Project Sources and Headers.

So, this header isn't includes in executables and CLion notifies you that some code insight features might not work properly. As workaround you can use "Mark directory as" Library Files/Project Source and Headers for folder.

Solution 2

Clion takes information about source files from CMake build system. When you add any cpp file to sources list CMake automatically tell about header with same name. So if cpp/h names differs (or you don't have cpp file at all) you should include header manually.

set(Sources my_lib.cpp)
set(Headers header_of_my_lib.h)
add_executable(superlib ${Sources} ${Headers})

If you don't have any executable you can omit last line, CLion will still know about files

Comments

[xaxxon]

is SOURCE_FILES some magic variable in cmake? I don't see any documentation on it.

[Azurespot]

It is mentioned here.

[xaxxon]

That doesn't mean that SOURCE_FILES is somehow an important variable to set from cmake's perspective.

[xaxxon]

Perhaps if SOURCE_FILES is then added to a target as a list of sources it does something, but without that, I'm not seeing anything that says it, on its own, does anything regarding the problem being asked about.

[xaxxon]

Also, the reason your "this won't work" part doesn't work is because you're SETTING (not appending) the variable each time. You can say set(SOURCE_FILES ${SOURCE_FILES} another_source_file.cpp) as many times as you want.

[Azurespot]

Ok thanks. I just relayed information from trial and error. When I tried to list the above in multiple lines, it would not work. It's my understanding the SOURCE_FILES is autogenerated from CLion when you create a project. Might not be in everyone's CMake. I was getting the same error as you, so this might help others.

[sjaustirni]

Please stop adding header files to executable. The proper workaround for this JetBrains bug is described in my answer.

[xaxxon]

regardless the part about you only getting one "set(SOURCE_FILES...)" is clearly wrong. You're just misusing the system and overwriting your previous changes, it's not some inherent limitation of cmake.

[Azurespot]

That could be, but it did not work for me to have multiple items in my SOURCE_FILES. Not sure why, but it did not work. If others have that problem, they should know they are not alone.

[xaxxon]

This is not a "it feels this way to me" kind of thing. This is a very clear "you did it wrong and now you're sharing bad information" kind of thing. Your answer is bad and wrong and should be removed because other people might believe you.

[sjaustirni]

You shouldn't include header files in the list of your source files. See my answer for the proper approach.

[Chris Kitching]

You can do better if you don't mind sacrificing the ability to build using Clion (I'm happy building on the command-line and having proper indexing in clion). CLion provides a CLION_IDE environment variable to cmake, so you can add header files to the sources array if ($ENV{CLION_IDE}), causing clion to index everything properly (but breaking your ability to actually use Clion's integrated build.

[Chris Kitching]

Notably: "Mark as project sources" will fail to handle things like include directories properly.

[sjaustirni]

@ChrisKitching But then you have CLion-specific stuff in your CMake file whilst using command line anyway. At that point you might as well ditch CMake file entirely and just use Makefile or do everything on command line. Also, I have never encountered improper behaviour while using Mark directory as Project Sources and Headers. What did you have a problem with exactly?

[xaxxon]

@ChrisKitching I have not experienced this shortcoming when doing exactly this. Can you verify you're still having this issue and either post another comment with more details or delete your previous comment?

[Chris Kitching]

@xaxxon Exactly which shortcoming are you referring to? "Mark as sources" not handling include dirs? My first comment "breaking the build"? Some things have changed now: CMake now correctly ignores headers in the source array (maybe edit answer). "mark as sources" attempts to guess which target to logically "attach" those sources to for the purposes of clion's indexing. This usually fails for all but very simple projects, leading to failed indexing. It's now moot, however, since you can just dump everything in the CMake target sources now and it'll work correctly.

[c z]

@sjaustirni CMake doesn't get confused. It's been argued (Bahadir, Meeting C++ 2019) that header files should always be included in the executable. If nothing else, it means the user's IDE gets the right answer when it queries CMake for the source files.

[sjaustirni]

@cz I have admittedly not watched the talk, but you do not need to include the header files into executable in order to get your IDE to understand your codebase and get Intellisense. If you look at my answer to this question you can see how it can be done without polluting your CMake targets with the header files.

[xaxxon]

Did you try the accepted answer? Did it not work? You should not need cmake workarounds for this.

[shizhen]

To be more specific, i cannot see option Mark directory as | Library Files/Project Sources and Headers

[xaxxon]

Probably because this question is about CLion.

[c z]

@sjaustirni It's at about 9 min in. The developers' argument is that the headers should be in the CMake file because it lets everyone know what project the header files belong to. They also say they're not needed and CMake is written to work with or without them, but IDEs should make use of them if they're there.

[sjaustirni]

@c z good point. It seems like a neat feature, thanks. My answer and the first comment actually predates this talk (and apparently, the feature itself), so I could not have known about it at the time. I'll look into if I can find time to update my answer :)