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?

Boudicca

Answer 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.

Fiasco

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. – Distill

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

@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? – Fiasco

@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? – Boudicca

@Boudicca 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. – Distill

this does not work for clion 2022.2.4, the option you mention does not even exist – Trilby

Answer 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

Insistence

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

@Fiasco 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. – Attenuant

@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. – Fiasco

@Fiasco 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. – Attenuant

@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 :) – Fiasco

Answer 3

In my case, My project is a Makefile project. I renamed a .c file then the CLion told me that this file doesn't belong to any project. So the reason is that the index is not up-to-date. After I did the "clean and reload Makefile project" the message disappeared automatically. The steps are followings:

1. Open the Build tool window from Main menu->View->Tool windows->Build
2. Click the "clean and reload Makefile project"

Done.

Braley

Answer 4

You can add the header files to your project like this:

set(SOURCE_FILES main.cpp MyClass1.cpp MyClass1.h MyClass2.cpp MyClass2.h)

You can also set it in multiple steps like so:

set(SOURCE_FILES main.cpp)
set(SOURCE_FILES ${SOURCE_FILES} MyClass1.cpp MyClass1.h)
set(SOURCE_FILES ${SOURCE_FILES} MyClass2.cpp MyClass2.h)

Though as mentioned in the comments, you probably shouldn't be adding the header files to your project at all.

Silicosis

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

It is mentioned here. – Silicosis

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

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. – Boudicca

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. – Boudicca

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. – Silicosis

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. – Boudicca

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. – Silicosis

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. – Boudicca

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

Answer 5

This warning is an IDE issue that Android Studio cannot recognise the current directory if it does not include any source files.

Workaround

Adding am empty source file, e.g empty_xxx.c under the directory in question and adding below line in your corresponding CMakeList.txt

add_library(${TARGET_NAME_XXX} SHARED ${SOME_DIR_HAVING_THIS_WARNING}/empty_xxx.c)

will help get rid of this warning.

Boots

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

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

Probably because this question is about CLion. – Boudicca