IDE для C/C++ для проектов со сложными билдсистемами

В qtcreator есть поддержка make проектов, в этом режиме можно указать дополнительные дефайны, так же параметры clang для анализа указываются в настройках проекта

Есть ещё возможность импорта команд для сборки в json формате, но это плохо работает

в этом режиме можно указать дополнительные дефайны

Ну так кто угодно может. Вопрос в том, есть ли IDE, способные вытаскивать дефайны и всё остальное из билдсистемы автоматически и с высокой точностью (а не эвристиками).

Есть ещё возможность импорта команд для сборки в json формате, но это плохо работает

Насколько плохо?

Только анализ кода, собирать не может. Анализ корректно работает

а в частности поддержка проектов с нетривиальными сборочными системами (в которых смысл кода существенно зависит от параметров компиляции)

Насколько нетривиальными? Пример можно привести?

KDevelop попробуй.

А так да, конкретики бы.

Насколько нетривиальными? Пример можно привести?

Linux, QEMU.

https://clang.llvm.org/docs/JSONCompilationDatabase.html

генерируешь clang compilation database (compile_command.json) сборочной системой. Её автоматически подхватит clangd, далее пользуешься любым редактором с поддержкой LSP. Т.е. тут не эвристики, а конкретные команды компиляции.

Если сборочная система это не поддерживает (т.е. это не cmake, meson и т.п.), то во-первых это хреновая сборочная система, во-вторых можно воспользоваться тулзами вроде bear и compiledb (они перехватывают вызовы компилятора и записывают их в нужном формате) или вручную передать опцию -MJ, если пользуешься clang

Эту compilation database не из всего можно так просто сгенерировать.

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

Ну нет, это не серьезно. Во-первых, С++. Если проект на С++ и действительно большой (скажем, компиляется около получаса не на ноутбуке) - то это 95% cmake , откуда вытекает, что это еще 95% MSVC. В том числе, для таргета linux@amd64. К тому же, С++ программисты всегда страдают и профессионально деформированы. (Давайте только сразу вынесем за скобки олдовые MFC- и подобные msvс only проекты, они лишь попортят статистику)

Во-вторых, если это Си, то начнем сразу с того, что Си-программисты страдают, это тоже их профессиональная деформация, и, боюсь, кроме всяких костылей типа tags нечего предложить. Ну как страдают, приспосабливаются, это работа такая.

Если цель, например, qemu, я делал как - ручками все файлики добавляешь аккуратненько в Qt Creator проект, создаешь несколько профилей под разные конфигурации… Или ручками же создаешь CMakeLists.txt , переписывая кривую штатную систему сборки (на такую же кривую, но зато свою). Кста, qemu вроде начал переход на cmake, но я давно не влезал туда. Потом, тебя достает бодаться с собственными кривыми копиями системы сборки, а в проекте уже начинаешь шарить. Поэтому, десяток открытых файлов в редакторе и make в консоли тебя уже удовлетворяют, а копаться и синхронизирировать системы сборки и подстраиваться под IDE, наоборот, раздражает.

Bonus points за умение работать вообще с произвольными сборочными системами

такие бонус поинтс в случае Си начисляются программистам! (или ты хочешь тут ссылку на https://github.com/rizsotto/Bear ? ну посмотри, игрушка, может помочь только как очередная тулза)

Понятно, у тебя все страдают и поделать с этим ничего нельзя не нужно. Не, смысл данного треда не в этом, страдать я и сам умею.

Не IDE, но скорее всего поможет https://www.sourcetrail.com/

Круто, не знал о нём. Вопрос поддержки им сложных билдсистем конечно остаётся открытым, но я потыкаю.

Там вроде по ссылке написано что-то про отслеживание

Да я сам бы ожидал от треда что-то хорошее. Выше упомянули Sourcetrail. Ну посмотри, подходит ли он для не-hello-world проектов…

Вот тебе еще ссылка, https://en.wikipedia.org/wiki/SlickEdit . Он даже живой, возможно его даже не переписали на Электроне. Лет 15 назад подход SlickEdit + Doxygen diagrams советовали для того, что бы разобраться в каком-нибудь большом проекте…

NetBeans посмотри.

codelite.org приятный редактор не на электроне, со всякими «перейти тудым/сюдым» :-)

внутри clangd про который выше сказали и lang.server для не C/C++

Clion хорош в разборе, подсветке и авто-компилите, но я думаю вы сами знаете его недостатки. Еще он, по моему, только в CMake умеет.

Еще он, по моему, только в CMake умеет

Может ещё с другими через compilation database.

О, оно еще и в ninja умеет, не знал

Нет. CLion также умеет в Make через анализ вывода Make (подобно NetBeans) и compilation database.

Если хочестся чего-то более «лёгкого», то можно попробовать VSCode с соотв. модулями.

Разве то что он умеет в CMake не значит, что он должен уметь и в Make?

P.S. Ну, то есть когда я писал про CMake, я предполагал и Make

Нет.

Потому что, внезапно, у CMake есть разные генераторы, напр., Ninja (cmake -G ninja).

И мало уметь собрать проект — нужно же понять, какие файлы компилируются и с какими флагами.

Средствами CMake получить эту информацию на порядок легче, чем средствами Make.

Мне Qt Creator нравится, там небольшой выбор билд систем, но мне очень нравится как он с кодом работает (подсветка, переходы, подсказки, переключения между хедерами и исходниками)

Eclipse с makefile, в makefile добавлена цель

#  specs_file has extension "C" for C++ and "c" for C.
discovery:
ifeq ($(extension),c)
    @echo -- discovery for $(CC)
    $(CC) $(INCS) $(CFLAGS) -E -P -v -dD '$(specs_file)'
else
    @echo -- discovery for $(CCX)
    $(CXX) $(INCS) $(CXXFLAGS) -E -P -v -dD '$(specs_file)'
endif
    $(RM) spec.d

Project->Properties->C/C++ General->Preprocessor Include Paths, Macros etc.->Providers:

• Снимаем все прички в списке «Providers»;
• Ставим причку на «CDT GCC Built-in compiler settings»;
• В настройках этого провайдера:

  • снимаем птичку «Use global provider shared between projects»;

  • в строке «Command to get compiler specs» прописываем:

    make extension="${EXT}" specs_file="${INPUTS}" discovery

Эклипса вызывает make discovery, достаёт все дефайны, и очень корректно парсит проект. Даже шаблоны разбирает.

NetBeans посмотри.

С каких пор он стал уметь в C/C++? Oracle до сих пор кормит завтраками.

Как это всё предполагает работать если часть, например define, пользователь будет передавать руками при конфигурировании?

Linux я правил в уже упомянутом QtCreator, вручную пробивая все инклуды, дефайны через встроенный импорт проектов без или с неподдерживаемой системой сборки.

На QEMU импорт compile_commands.json работает, но так себе.

Мощнее Emacs для си и с++ ничего нет

https://www.jetbrains.com/ru-ru/clion/

но уже насоветовали

На QEMU импорт compile_commands.json работает, но так себе.

Вы поддержку Elbrus в QEMU тоже в Qt Creator’е пилите?

Твоим требованиям удовлетворяет почти любой современный текстовый редактор с поддержкой LSP, IDE для этих задач - оверкилл.

Если сборочная система не умеет в compilation database - то всегда есть bear

Искусственный интеллект ещё не изобрели. Как IDE должна угадать принципы работы сборочной системы? Может там кастомные баш-портянки.

Вообще тебе нужно что-то типа трекера из анализатора пивас-студио. Он там просто отслеживает запуски компилятора и записывает все ключи, с которыми был вызван компилятор. Если бы IDE могла такое делать, то можно было бы запустить кастомную билд систему и оттрекать все файлы, инклюды и ключи.

Оно настолько «так себе» что я в итоге им не пользуюсь.

Гораздо проще в Kate уже написать. Да, автодополнение примитивное и не учитывает инклудов, но хотя бы не мешается.

QEMU сильно обмазан макросами и сгенерированными файлами. У QtCreator просто от этого едет крыша.

Да, автодополнение примитивное и не учитывает инклудов, но хотя бы не мешается

Даже с ЛСП?

LSP лишь модное словечко. Да, он что-то сглаживает, но проблемы редактора он не исправляет.

Ай, я почему-то подумал про QtC. У самого крыша уже тоже того.

Нет, в Kate я его ни разу не включал.

Я CDT использую, в настройках проекта выключаю генерацию всяких мейкфайлов и указываю команду сборки (шеловский скрипт который настраивает окружение и запускает билд процедуру)

Плюс у CDT есть возможность указать внешнюю тулзу которая распишет дефайны, инклуд пасс и прочие параметры сборки для проекта - я ей подсовываю свой скрипт который все это выдергивает из настройки билд системы и уже на основе этой инфы CDT строит базу данных для автокомплита, подсветки и ерорчека в редакторе.

Когдато давно делал тоже самое для VSE но уже давно им не пользовался, но вообще он полутчше был чем CDT - незнаю как сейчас.

В Qt Creator есть плагин для поддержки autotools проектов

поддерживаю — хотел сам оставить коммент про vim (nvim) с LSP сервером. — сам использую coc — прекрасно парсит все, если есть данный файлик.

Если проект на С++ и действительно большой (скажем, компиляется около получаса не на ноутбуке) - то это 95% cmake , откуда вытекает, что это еще 95% MSVC.

Лови виндузятника..

NetBeans

С каких пор он стал уметь в C/C++?

Давно: https://netbeans.apache.org//kb/docs/cnd/quickstart_ru.html

$ export CC=log-cc-and-generate-project-sln.sh
$ build

Остальное навесишь по вкусу, проблем просто нету.

Давно перестал уметь*

в которых смысл кода существенно зависит от параметров компиляции

Изобретателей таких «билд-систем» к разработке нельзя подпускать на пушечный выстрел.

emacs с плагинами со всем справляется

В 8.2 умел. В новых версиях 12.x плагин никак не доделают, а из 8.2 он кое-как совместим.

поддержка проектов с нетривиальными сборочными системами

Это сама по себе проблема, которую следует решать.

NetBeans

Он умер, в последних версиях вообще С/С++ выпилили и приходится старый плагин ставить. Если уж брать IDE «общего назначения», то CLion.

Умел до 8 версии включительно.

LSP - несмешной мем.