Ололо про поддержку IDEшками различных систем сборки

CMake

Так ли нужны списки? Можно проектом считать все файлы в каталоге проекта, как это делает KDevelop.

Список больше нужен виндузятническим IDE, которые сами себе система сборки.

Списки нужны. Некоторые файлы логичней объединить иначе, чем это сделано системой поддиректорий. Некоторые файлы не нужно видеть в IDE, а некоторые, казалось бы не имеющие отношение к программированию – нужно.

А что вообще нужно IDE знать про систему сборки?

Ничего. А зачем?

Списки именно файлов как уже заметили - не нужны, причем даже Visual Studio, которая уже не первый год как умеет показывать просто содержимое каталогов.

А вот что надо, для С и С++ - это include path, compile definitions, чтобы правильно делать автодополнение, показывать активные блоки условной компиляции. Это прям такой минимум. Для Java - classpath/module path. Ну и для остальных по аналогии.

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

IDE - это не текстовый редактор, слово integrated там не просто так.

Я не уверен, что разделение имеет хоть какой-то смысл в 2022. Потому что те же emacs и vscode могут запустить сборку и выплюнуть лог с ошибками. Но IDE их никто не зовёт.

Запуск сборки - это малая часть того, что делает IDE.

Огласите весь список, пожалуйста! Те IDE, которые я пробовал (IntelliJ), в основном пердели и тормозили.

Списки файлов нужны. Содержимое директории и дерево проекта – вещи разные.

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

Вот поэтому я и интересуюсь стандартом, где все эти нюансы (в том числе и неочевидные) уже продуманы.

Вот всё-таки это специфично как минимум для языка. Стандарта я не видел, но можно, например, посмотреть на CMake File API - https://cmake.org/cmake/help/latest/manual/cmake-file-api.7.html

Есть Compilation Database: https://clang.llvm.org/docs/JSONCompilationDatabase.html

CMake умеет генерировать, для make есть bear, не знаю насколько он хорошо работает в целом, но когда я использовал – все работало, как надо. Думаю, meson тоже такое умеет генерировать.

еще команды компиляции, чтобы знать, какой применяется стандарт языка и какие заданы дефайны. Из всего этого де факто стандартизирована только JSON compilation database. Даже не столько стандартизирована, сколько есть возможность выцепить ее отовсюду даже без явной поддержки. А в остальном кто в лес, кто по дрова. Куча проектов вообще на make-файлах.

системы сборки и фик бы с ними, но вот почему VCS ничего кроме git и svn не ставят ?

Хотя типичные действия там почти одинаковы и к IDE они имеют первостепенное отношение.

ЕМНИП, чего то универсального не существует.

Например такая система сборки как Qbs сама предоставляет все для ИДЕ.

Суть в том, что любая ИДЕ имеет некое свое АПИ для отображения списка файлов проекта, подсветки синтаксиса и прочего.

И если хотим использовать какую нибудь систему сборки, то надо написать плагин для ИДЕ, который подружит АПИ ИДЕ и АПИ системы сборки.

Ничего сложного. Например Qbs поддерживает JSON подобный протокол, через пайпы с помощью которого можно спросить у системы сборки всю информацию о проекте. Дефайны компилятора, заголовки компилятора, флаги сборки и список артефактов и всякое разное.

Т.е. плагин ИДЕ запускает процесс ,екзеху самого Qbs в режиме сессии и шлет ему команды. Т.е. сама ИДЕ ничего не знает о проекте, и не должна знать, а получает уже все на блюдечке.

Очень легко интегрировать в любую ИДЕ, в отличии от того же говно CMake.

а чем cmake file api хуже этого самого? Тем более там не json-подобный протокол, а просто json

Как я понял:

• Смаке всегда генерит это в виде JSON файлов, которые при каждом чихе пересоздаются. И нужно перечитывать их каждый раз (или не так?).

• Эти JSON файлы какие-то громоздкие, такие себе черные ящики, и как-то не внушает кол-во экспортируемых свойств.

• Смаке не отслеживает само изменения (нет некоего сервиса/службы для этого), т.е. ИДЕ должна смотреть что что-то поменялось, формировать запрос для СМаке в виде JSON query файлов, запускать сам Смаке чтобы он перегенерил результирующий ответ в виде JSON файла… буээ..

В Qbs там по другому:

1. Запускается сам Qbs в режиме сессии (как отдельный процесс с некими аргументами) и постоянно висит активным.

2. ИДЕ «коннектится» к этому процессу и запрашивает инфу по проекту (вплоть до каждого свойства проекта/продукта/артифакта, флаги сборки, дефайны и прочее, которые настроены в проекте).

3. Весь обмен осуществляется в JSON формате (запрос/ответ/уведомление).

4. При изменениях в проекте/файлах и прочее, Qbs сам уведомляет ИДЕ об этом. т.е. не надо «перечитывать все заново», достаточно только получить кусочек изменений.

5. Qbs сам уведомляет об ошибках, начале/конце сборке (вплоть до репорта оставшегося времени, прогресса).

и прочее.. все это через JSON API протокол через пайпы.

Я не знаю, могет ли Смаке так же здорово все это делать.

в cmake раньше был такой режим, cmake-server. От него отказались в пользу file api из-за проблем с производительностью на больших проектах. Вот тут можно почитать дискуссию: https://gitlab.kitware.com/cmake/cmake/-/issues/17753

Да, я в курсе. Это все Смаке проблемы.

а некоторые, казалось бы не имеющие отношение к программированию – нужно.

Это основная проблема. Такие файлы (к примеру, README.md) нафиг не нужнны системе сборки и никто не удосуживается их туда добавить. Как следствие, не отображаются.