Здравствуйте, alex_public, Вы писали:

_>Здравствуйте, noone, Вы писали:
_>Собственно вы повторили в точности мою мысль, только своими словами. Задам вам простейший вопрос уже в вашей терминологии: а зачем ide читать "модель проекта"? Сборкой то в любом случае занимается не она, а сторонняя система сборки.

Я в прошлом посте на пол-страницы распинался, рассказывая зачем. Потому что в C++ нет исходных файлов, а есть зависящие от контекста единицы компиляции. Для того, чтобы понять что написано в этой конкретной единице, вы должны повторить все шаги системы сборки и получить на входе все нужные опции и такое же, как при сборке, расположение/содержание других файлов на диске. Существуют (полу)декларативные модели проекта, откуда это можно дешево вычитывать (см. VS, Xcode), но CMake к ним не относится, его приходится заставлять такую модель генерировать (см. загадочная папка).

_>Я вроде бы достаточно чётко описал реализацию этого простейшего движения (собственно оно имеется во всех конкурирующих IDE). Это возможность запуска произвольной команды (а будет это make/nmake/waf/scons или вообще bat файл решает пользователь в простейшей настройке) по нажатию кнопки build в IDE. В таком случае будут одинаково отлично работать и студенческая поделка и проект с километровым конфигом в CMakeLists.txt.

Это программы будут отлично собираться и работать. А IDE работать не будет, потому что нужных настроек компиляции и правильного окружения у нее нет.

_>Что касается настроек, необходимых для работы анализатора кода, то это совсем другой вопрос. Настройка там всегда одинаковая, тривиальная (всего то пара опций) и во всех нормальных IDE делается за пару минут, в том числе и под несколько конфигураций. Я это делал не раз и в разных IDE. И никаких сложностей не встречал.

Возможно, что у вас в программе пара опций. Это очень хорошо, вы легко напишете двухстрочный CMakeLists.txt и вот вам паллиатив до момента поддержки более удобных для вас моделей. Но CLion должен поддерживать все корректно настроенные проекты, и показывать при этом что-то более осмысленное, чем редактор с подсветкой текста. Вы предлагаете разработчикам LLVM переписать все опции под все платформы в удобном для IDE виде, а потом поддерживать одно и то же в двух разных местах? Возьмите упоминавшийся проект http://www.itk.org/ и сформулируйте "пару опций", которые для каждой единицы компиляции эквивалентны тем, что получаются у CMake сейчас. Плюс позволяют как-то легко сгенерировать необходимые файлы из имеющихся болванок. Для 4-х платформ — Win 64, OS X 32, OS X 64, Linux 32 (всякие IRIX и AIX пока пропустим), и двух фронтендов — GCC, Clang.

_>Ну так и настройки анализатора кода нужны только CLion — вот там им и самое место.

Настройки анализатора кода ("отслеживать неприсвоенные переменные или забить", "искать бесконечные циклы или забить" и т.п.) как раз в .idea и хранятся. А настройки компиляции и окружения, без которых до анализа кода дело не дойдет, хранятся в CMakeLists.txt, где их все равно уже пишет и поддерживает автор программы. При открытии проекта они распаковываются с помощью CMake во временную папку в относительно удобоваримом для CLion виде.