Здравствуйте, noone, Вы писали:
N>Я в прошлом посте на пол-страницы распинался, рассказывая зачем. Потому что в C++ нет исходных файлов, а есть зависящие от контекста единицы компиляции. Для того, чтобы понять что написано в этой конкретной единице, вы должны повторить все шаги системы сборки и получить на входе все нужные опции и такое же, как при сборке, расположение/содержание других файлов на диске. Существуют (полу)декларативные модели проекта, откуда это можно дешево вычитывать (см. VS, Xcode), но CMake к ним не относится, его приходится заставлять такую модель генерировать (см. загадочная папка).
У нас странная дискуссия. Вы рассказываете почему это точно не может работать из каких-то общетеоретических соображений, а я вам отвечаю что вот оно у меня перед глазами отлично работает. Может стоит просто взять и попробовать самому указанные мною схемы? ) А то меня как-то напрягает тратить своё время на убеждение людей в том, что это земля вращается вокруг солнца, а не наоборот.
N>Это программы будут отлично собираться и работать. А IDE работать не будет, потому что нужных настроек компиляции и правильного окружения у нее нет.
И что мешает настроить это в окошке IDE? Как собственно и реализовано во всех конкурентах CLion? )
N>Возможно, что у вас в программе пара опций. Это очень хорошо, вы легко напишете двухстрочный 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.
Ещё раз: у вас общетеоретические рассуждения, почему это не может работать (а вы хоть пробовали?), а у меня конкретная практика перед глазами. Причём на проекте использующем тяжёлые кроссплатформенные (т.е. куча этих самых ifdef в них) библиотеки типа boost, wxWidgets, OpenCV и имеющим много разных конфигураций сборки. Да, и кстати собирающимся под кучу разных платформ (правда это никак не пересекается с конфигурациями — каждая из них собирается везде). Так вот в Netbeans анализатор кода превосходно всё видит и для этого потребовалась всего несколько минут на его настройку (те самые указания каталогов заголовочных файлов и директив препроцессора). Более того, до этого у меня не было проблем с аналогичным в Eclipse, а до этого в VisualStudio. Почему-то во всех приличных IDE есть такие настройки. Наверное потому, что они не предназначены для "серьёзных" проектов?
N>Настройки анализатора кода ("отслеживать неприсвоенные переменные или забить", "искать бесконечные циклы или забить" и т.п.) как раз в .idea и хранятся. А настройки компиляции и окружения, без которых до анализа кода дело не дойдет, хранятся в CMakeLists.txt, где их все равно уже пишет и поддерживает автор программы. При открытии проекта они распаковываются с помощью CMake во временную папку в относительно удобоваримом для CLion виде.
Кстати говоря, настройки каталогов заголовочных файлов обычно делаются у меня даже не под проект (ну точнее там тоже настраивается иногда, но уже мелочи по папкам внутри проекта, а не по внешним библиотекам), а просто в IDE, глобально на все проекты. Так что настройка конкретного проекта чаще всего сводится к банальным указаниям специфических опций препроцессора (далеко не всех, что передаются компилятору про сборки, а только влияющих на анализ кода) под каждую конфигурацию.
