This file does not belong to any project target как решить проблему

и даже автодополнение для угловых скобок для вызовов ядра:

Примечание: для тестов и скриншотов использовался настоящий CUDA-проект с GitHub: ClaraGenomicsAnalysis.

Нас спрашивали, почему же мы так сфокусировались на CUDA, а не других специфических областях, например Qt. Если коротко, то мы бы, конечно, хотели поддержать все типы проектов на C/C++ в нашей IDE. Но в условиях ограниченных ресурсов приходится делать выбор и скорее сосредоточиться на поддержке максимально универсальных возможностей. Такие диалекты, как CUDA, если не поддерживаются «из коробки», то приводят к красному коду, ошибкам анализатора кода и другим проблемам с основными возможностями IDE. В отличие от Qt, где общий парсер вполне справляется с кодом и только не хватает каких-то специфических возможностей.

Для разработчиков встроенных систем

Мы продолжаем работу по поддержке разработчиков встроенных систем. Благодаря взаимодействию с компанией IAR Systems AB мы смогли получить партнерские лицензии и добавить в CLion поддержку компилятора IAR. Раньше мы не могли правильно считать информацию от компилятора и такие проекты не загружались в CLion корректно. Теперь все работает!

Стоит отметить, что для использования компилятора требуется использовать тулчейн MinGW. А вот здесь можно найти несколько советов о том, как использовать CMake с IAR Embedded Workbench.

Мы продолжим сотрудничество с IAR Systems AB, и, надеюсь, в один прекрасный день в CLion также появится поддержка их отладчика.

С самого первого релиза CLion мы общались с создателями PlatformIO, уникальной экосистемы для быстрого старта проектов под встроенные системы. Например, многим она помогла начать первый проект на Arduino. К релизу 2020.1 мы собрали хоть и довольно базовый, но полезный плагин PlatformIO for CLion. Самая главная его возможность — создать проект для PlatformIO на основе CMake, для этого достаточно выбрать такой тип проекта в мастере создания новых проектов:

Плагин автоматически создает конфигурации запуска и отладки, специфические для PlatformIO, а также позволяет отлаживать с помощью отладчика PIO Unified Debugger прямо из CLion. Больше информации можно найти в официальной документации. Пробуйте и пишите ваши пожелания по дальнейшему развитию — мы сейчас как раз раздумываем, куда и как развивать этот плагин дальше.

Обновленная интеграция с инструментами Clang

Как уже известно, мы сейчас активно портируем все больше и больше возможностей на языковой движок на основе Clangd. Во-первых, чтобы быстрее получать поддержку новых возможностей языка и адаптировать действия IDE для них, а, во-вторых, чтобы в некоторых случаях улучшать производительность редактора (не везде, к сожалению, Clangd является таким универсальным средством).

В релизе 2020.1 мы много времени уделили исправлениям в автодополнении на основе Clangd (оно появилось в версии 2019.3). И, решив, что результаты у такого подхода довольно хорошие, включили по умолчанию режим, в котором опции для автодополнения берутся полностью из Clangd. Включить обратно смешанный режим работы можно в настройках:

Но мы не рекомендуем этого делать без веских на то причин, так как объединение результатов от двух разных провайдеров может вызвать проблемы с приоритетами. К тому же, судя по нашим измерениям, новое автодополнение на базе Clangd не медленнее, а зачастую и быстрее встроенного.

На Clangd в этом релизе также переехал анализ потока данных (DFA). Этот анализатор заслуживает отдельной статьи, ибо умеет и делает то, чего не делают обычно компиляторы (в основном потому, что им это не нужно, хотя теоретически это возможно и на их стороне воспроизвести) — анализирует, как данные движутся по графу потока управления и, исходя из этого знания, находит потенциальные ошибки. Например, условия, которые всегда истинны или ложны, бесконечные рекурсии и циклы, пропущенные return-выражения, неиспользуемые значения, параметры и локальные переменные:

Теперь это все работает на Clangd. И мы надеемся, что это улучшит производительность анализов кода на ваших проектах. К сожалению, раньше нам часто приходилось советовать пользователям отключить именно анализ DFA для улучшения производительности редактора. Если это ваш случай — предлагаем вам включить анализатор обратно. Будем ждать ваших отзывов в нашу техподдержку и трекер.

В довершение про инструменты Clang стоит отметить улучшения в поддержке Clang-Tidy и ClangFormat:

• При обнаружении в проекте конфигурационного файла .clang-tidy CLion автоматически отключает настройки Clang-Tidy в IDE и переходит на использование данного конфигурационного файла. Поведение управляется настройкой.
• При обнаружении в проекте конфигурационного файла .clang-format CLion автоматически переключается на использование ClangFormat как инструмента форматирования кода на данном проекте. Если же вы решили переключиться на ClangFormat, но подходящего конфигурационного файла в вашем проекте нет, то CLion предложит его создать, выгрузив туда текущие настройки форматирования.

Для разработчиков на Windows

Если на Linux и macOS тулчейн в CLion выбрать довольно просто (берем либо GCC, либо Clang), то на Windows существует множество опций, в которых нелегко разобраться: Cygwin, MinGW/Mingw-w64, WSL, Visual Studio. При этом в рамках каждого тулчейна зачастую используют разные компиляторы. Нас долго просили о возможности использования Clang на Windows. И в CLion 2020.1 появилась возможность взять Clang-cl (либо с официального сайта LLVM, либо вместе с инструментами Visual Studio) и использовать его в рамках тулчейна Visual Studio:

Кстати, вы заметили отладчик, выбранный по умолчанию в этом диалоге? Тот самый отладчик на базе LLDB для тулчейна Microsoft Visual C++, который разрабатывает наша команда и который мы представили в прошлом году, включен в новой версии по умолчанию! Правда, если вы хотите воспользоваться также поддержкой Native Visualizers, ее все же надо явно включить в настройках: Settings | Build, Execution, Deployment | Debugger Data Views | Enable NatVis renderers for LLDB.

Рефакторинг Change Signature

Среди множества рефакторингов в CLion выделяется Change Signature (Ctrl+F6 на Windows и Linux, ?F6 на macOS). Он позволяет изменить имя функции, тип возвращаемого значения, список параметров. При этом IDE обновляет все использования функции, чтобы сохранить корректность кода. Но что делать, если вы добавляете новый параметр? Раньше CLion во все использования проставлял значение типа по умолчанию (если оно есть) – 0 для чисел, nullptr для указателей. Теперь же, с версии 2020.1, появилась возможность указать значение, которое CLion подставит в использования функции, прямо в диалоге рефакторинга:

Если не указать ничего, то поведение будет как раньше.

Конфигурации запуска и отладки

Множество небольших улучшений в конфигурациях запуска и отладки в CLion сделало их гораздо более удобными в использовании.

Во-первых, конфигурации Remote GDB Server и Embedded GDB Server работают теперь с кастомными таргетами, а не только с таргетами CMake. Так что теперь отлаживаться на удаленной машине или на микроконтроллере можно не только в случае проекта на базе CMake, но и для любого другого типа проекта, для которого вы настроили кастомные таргеты (указав команды сборки и очистки проекта).

Во-вторых, для конфигураций типа CMake, Custom Build и Gradle Native Applications появилась возможность использовать макросы и переменные путей. С их помощью можно получить доступ ко многим полезным значениям:

И, наконец, в этих же типах конфигурации появилась опция перенаправления ввода программы. В сочетании с макросами Prompt/FilePrompt, она позволяет не только перенаправить ввод в программу из файла, но и показать диалог для выбора файла для ввода на старте конфигурации:

Обновления форматтера, улучшения редактора и многое другое

Стоит упомянуть еще несколько небольших точечных улучшений в разных подсистемах:

• Отдельные настройки именования для полей структур и полей классов.
• Возможность сворачивать блоки кода, выделенные при помощи #pragma region / #pragma endregion .
• Окно просмотра документации теперь можно не только вызывать по шорткату, но и увидеть просто при наведении мышкой на интересующий символ.
• Шрифтом по умолчанию в IDE теперь является JetBrains Mono — новый моноширинный шрифт от JetBrains, созданный специально для разработчиков и помогающий оптимизировать читаемость кода.
• Светлая тема по умолчанию теперь одинаковая на всех трех платформах – IntelliJ Light.
• Сессии терминала можно разбивать на несколько по горизонтали или вертикали. Таким образом, несколько сессий видно одновременно в одном табе.
• Из платформы IntelliJ приехали также улучшения в интеграции с системами контроля версий.

CLion Ask Me Anything

Онлайн-сессия вопросов и ответов (на английском) с разработчиками из команды CLion запланирована на 7 мая. В сессии примут участие члены команды, отвечающие за следующие подсистемы:

• Языковая поддержка C и C++, движок на базе Clangd, адаптация новых стандартов языка C++ в CLion.
• Проектные модели.
• Отладчики.
• Форматирование кода (как родным инструментом, так и с помощью ClangFormat).
• Модульное тестирование и интеграция с различными фреймворками.
• Разработка встроенных систем.
• Удаленная разработка.

На этом на сегодня все. Дочитали до конца? Спасибо вам огромное за внимание! Пишите вопросы, предложения, восклицания в комментариях — мы всегда с радостью их читаем и отвечаем!

Команда CLion
The Drive to Develop

К сожалению, не доступен сервер mySQL

In CLion, header only library: 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?

asked Sep 15, 2017 at 18:42
19.3k 5 5 gold badges 50 50 silver badges 83 83 bronze badges

5 Answers 5

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 $

include_directories("$/inc/") add_subdirectory(src) add_executable($ main.cpp $) 

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.

C++ – In CLion, header only library: file “does not belong to any project target, code insight features might not work properly”

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 $) 

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?

Best Solution

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 $

include_directories("$/inc/") add_subdirectory(src) add_executable($ main.cpp $) 

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.

Related Solutions

C++ – CMake: target_include_directories() prints an error when I try to add the source directory itself, or one of its subdirectories

The origin of the problem is not the target_include_directories command itself, but the attempt to install a target that has a public or interface include directory prefixed in the source path.

While it is perfectly fine and desirable to use absolute paths when building the library from scratch, a third party library that pulls in a prebuilt version of that library will probably want to use a different include path. After all, you do not want all of your users to mirror the directory structure of your build machine, just to end up in the right include path.

CMake’s packaging mechanism provides support for both of these use cases: You may pull in a library directly from the build tree (that is, check out the source, build it, and point find_package() to the directory), or from an install directory (run make INSTALL to copy built stuff to the install directory and point find_package() to that directory). The latter approach needs to be relocatable (that is, I build and install on my machine, send you the resulting directory and you will be able to use it on your machine from a different directory structure), while the former is not.

This is a very neat feature, but you have to account for it when setting up the include directories. Quoting the manual for target_include_directories :

Include directories usage requirements commonly differ between the build-tree and the install-tree. The BUILD_INTERFACE and INSTALL_INTERFACE generator expressions can be used to describe separate usage requirements based on the usage location. Relative paths are allowed within the INSTALL_INTERFACE expression and are interpreted relative to the installation prefix. For example:

target_include_directories(mylib PUBLIC $/include/mylib> $ # /include/mylib ) 

$

Content of . when the property is exported using install(EXPORT) , and empty otherwise.

$

Content of . when the property is exported using export() , or when the target is used by another target in the same buildsystem. Expands to the empty string otherwise.

How to get CLion to run an install target

UPDATE: As of 2018.1 EAP, build 181.3741.16, CLion supports running cmake install if your project defines install targets:

Original Answer:

I don’t think that CLion implements this feature yet. However, you can work around this limitation by adding a CMake «custom target» (using add_custom_target() ) that will execute the make install command:

add_custom_target(install_$ $(MAKE) install DEPENDS $ COMMENT "Installing $") 

Now, all you have to do is «build» the install_YOUR_PROJECT_NAME target from the «targets» menu in CLion.

Update:

A more cross-platform technique might be the following:

add_custom_target(install_$ "$" --build "$" --target install DEPENDS $ COMMENT "Installing $") 

This file does not belong to any project target как решить проблему

First time here? Check out the FAQ!

Attention: Answers.ros.org is deprecated as of August the 11th, 2023. Please visit robotics.stackexchange.com to ask a new question. This site will remain online in read-only mode during the transition and into the foreseeable future. Selected questions and answers have been migrated, and redirects have been put in place to direct users to the corresponding questions on Robotics Stack Exchange. Additional details are available here.

The site is read-only. Please transition to use Robotics Stack Exchange
CLion: This file does not belong to any project target
clyde
1247 ● 27 ● 54 ● 51

When I use CLion on a ROS project, I get the following banner when looking at .h files: This file does not belong to any project target, code insight features might not work properly. Any insight?

mkdir -p ~/catkin_ws/src cd catkin_ws catkin_make source devel/setup.bash cd src git clone https://github.com/ros/geometry.git # Can be anything cd .. catkin_make ~/clion-2017.2.3/bin/clion.sh src/CMakeLists.txt 

Then open any .h file to see the banner. Code completion works fine in .cpp files.

Thanks in advance!

Comments

Hi Clyde. I have the same issue with Clion 2017.2.3 It does NOT happen (i.e. the .h file is seen correctly) in Clion 2017.1.3 It seems like that you’re using 2017.2.3 as well (from the last line of your code snippet).