Comments 63
По поводу новой фичи Clangd: он у меня течёт в sles, так что пришлось отключить.
Касательно производительности: на больших файлах всё ещё лютые фризы, надеюсь поправите к следующему релизу.
А можно чуть больше деталей про утечки: suse linux? Как именно видно утечки, какие логи/дампы смотрите? Какие-то конкретные сценарии работы с IDE при этом или просто открываете проект и более особо ничего? Движок на clangd пока экспериментальный, ваш репорт будет очень полезен, наверняка мы что-то упустили.
Про фризы — вы CPU снэпшоты нам не репортили? Просто понять, это что-то новое или просто еще непофикшенное старое. Если репортили, можно номер тикета напомнить.
Про фризы — вы CPU снэпшоты нам не репортили? Просто понять, это что-то новое или просто еще непофикшенное старое. Если репортили, можно номер тикета напомнить.
К сожалению, сейчас нет доступа к машине и проверить подробности утечки не могу. Помню что через несколько сборок проекта (через make) cland начал есть слишком много памяти. Отключение помогло.
Фризы точно не новые, потому что мучаемся с этим достаточно давно. Репорты емнип не отправляли, ибо там похожих тикетов и так много. Файл большой (30к строк), может проблема в макросах.
А «слишком много» — это сколько? И что при этом открыто в редакторе? Попробую пояснить вопрос — 1.5-2Гб в некоторых случаях, при нескольких больших открытых файлах в редакторе, это норма.
~1гб, но этого оказалось достаточно, чтобы забить до упора память моей машины.
> при нескольких больших открытых файлах в редакторе
Проект как раз был небольшой, и файлов крупных не было. Максимум 500 строк.
> при нескольких больших открытых файлах в редакторе
Проект как раз был небольшой, и файлов крупных не было. Максимум 500 строк.
А заголовочные файлы большие/много?
Инклюдов прилично (llvm, clang-lib), считаете в этом дело? Если так, то 2гб «хватит всем»?
Возможно. А проект случайно не OS? Посмотреть не получится?
В целом, стоит понять, там память течет или ее просто (почему-то) много требуется для работы clangd. К сожалению, в экспериментальной версии пока не много вариантов посмотреть какие-то логи и всякую отладочную инфу. Завтра командой подумаем, как вообще нам такое более удобно диагностировать и какие логи от вас нам могут помочь.
В целом, стоит понять, там память течет или ее просто (почему-то) много требуется для работы clangd. К сожалению, в экспериментальной версии пока не много вариантов посмотреть какие-то логи и всякую отладочную инфу. Завтра командой подумаем, как вообще нам такое более удобно диагностировать и какие логи от вас нам могут помочь.
Чтобы избежать ложных срабатываний, алгоритм отключается автоматически для очень коротких имен (менее 3 символов).
А можно все же включать для переменных с названиями типа
vx, vy, vz
x1, x2, x3
?
Например, если имя переменной соответствует (.+)[xyz]|[xyz](.+)?
Планируется ли что-то делать с инспекциями кода, а точнее с тем, что на больших файлах (да практически любой файл из LLVM) во время запуска инспекций кода помечается как «Too complex». Особенно заметно на больших header-only библиотеках. Тикет в багтрекере висит, но непонятно, планируется ли это фиксить.
Планируется, конечно) Если коротким ответом.
Если чуть более вдаваться в детали, то такая ошибка выдается вполне конкретной инспекцией, а не всеми, – Data Flow analysis. Ее можно отключить, если ошибка сильно мешает.
Но вообще DFA правда может быть очень сложным. Хотя, конечно, бывает, что просто из-за проблем в парсере такая ошибка в инспекции. Проблемы парсере — у нас в приоритете, но за этой ошибкой too complex может скрываться столько разных случаев / причин / проблем, что вот взять и починить все и сразу пока не получается.
Если чуть более вдаваться в детали, то такая ошибка выдается вполне конкретной инспекцией, а не всеми, – Data Flow analysis. Ее можно отключить, если ошибка сильно мешает.
Но вообще DFA правда может быть очень сложным. Хотя, конечно, бывает, что просто из-за проблем в парсере такая ошибка в инспекции. Проблемы парсере — у нас в приоритете, но за этой ошибкой too complex может скрываться столько разных случаев / причин / проблем, что вот взять и починить все и сразу пока не получается.
Ну просто насколько я помню в тикете отписали, что там есть какие-то ограничения движка. Если отключаете проверку из-за того, что проверка может занимать слишком много времени, то я бы согласился на Opt-In опцию с предупреждением, что это может сильно замедлить анализ. Так как вполне вероятно, что у меня на компьютере довольно неплохой процессор с достаточным даже для CLion обьёмом оперативной памяти, что я готов пойти на такие жертвы ради инспекций :-)
Анастасия, а можно чуть подробнее о причинах побудивших задействовать clangd?
Спрашиваю потому, что давным-давно (кажется в FB) я советовал вам идти этим путем, а вы не соглашались…
Спрашиваю потому, что давным-давно (кажется в FB) я советовал вам идти этим путем, а вы не соглашались…
Не совсем правда, что мы не соглашались.
Но мы в общем то никогда не скрывали, что смотрим на разные другие решения для парсера и clang одно из них.
А сейчас просто нашлись ресурсы, чтобы этим заниматься. + Пришло понимание, как бы подружить clang и нашу платформу. + Мы научились дружить clangd и наш собственный парсер, чтобы они работали одновременно и не мешали друг другу. В общем сложилась благоприятная обстановка, чтобы что-то реально попробовать и показать пользователям. Надеемся, что получилось неплохо.
Насколько это экспериментальное решение станет постоянным, я пока не могу сказать. Время покажет.
- Мы всегда говорили, что есть причины, почему clang не был выбран изначально (исторические платформенные ограничения).
- Есть (до сих пор) сомнения, что на clang можно решить все необходимые для IDE задачи, потому что это компилятор и он архитектурно предназначен для других задач.
- Не понятно пока, получится ли на нем сделать global refactorings и прочие умные штуки на всем проекте, а если и получится, то будет ли это достаточно быстро работать.
Но мы в общем то никогда не скрывали, что смотрим на разные другие решения для парсера и clang одно из них.
А сейчас просто нашлись ресурсы, чтобы этим заниматься. + Пришло понимание, как бы подружить clang и нашу платформу. + Мы научились дружить clangd и наш собственный парсер, чтобы они работали одновременно и не мешали друг другу. В общем сложилась благоприятная обстановка, чтобы что-то реально попробовать и показать пользователям. Надеемся, что получилось неплохо.
Насколько это экспериментальное решение станет постоянным, я пока не могу сказать. Время покажет.
Для того, чтобы эффективно использовать clang в IDE (как парсер) — clang надо правильно готовить и патчить. Как правильно написала Анастасия, кланг — это, в первую очередь, компилятор. И ведёт он себя с кодом как компилятор, а не как IDE — более строго. И работает он, мягко скажем, не быстро. А чтобы заставить работать быстро — надо колдовать. Да и после колдовства (если не лезть глубоко в реализацию парсера) некоторые фишки просто не будут работать. Например, о фичах типа «создать декларацию функции из определения» или «создать декларацию из использования» можно будет забыть — кланг для таких кусков кода просто не построит адекватную AST (код для него, как компилятора, будет невалидный). Про адекватную работу код-коплита внутри шаблонов тоже можно будет забыть, передав привет двухфазному парсингу. В общем, дружить clang и IDE — весело. И больно.
Обновился, радуюсь. Вопрос возник по выравниванию кода после вложенных циклов.
Пишу что-нибудь такое
for (int i = 0; i < 2; ++i)
for (int j = 0; j < 3; ++j)
for (int k = 0; k < 3; ++k) {
int s1 = i * i;
int s2 = j + k;
}
std::cout << "incorrect indentation\n";и после этого выравнивание идет по закрывающей фигурной скобке. Code->Reformat Code приводит все в порядок, то есть строка после цикла будет с тем же отступом, что и внешний for. Вставка пустой строки не помогает.
Похоже на багу. И кажется, оно так работало и в форматере на парсере, и в новом форматере на лексере( Занесли в трекер OC-17542
Я не знаю как правильно сформулировать вопрос, по этому попробую описать ситуацию…
Существует разрабатываемый энтузиастами плагин для IDEA I-Pascal, для поддержки языка pascal соответственно. При этом он строится на проектной (модульной) модели IDEA. Но на самом деле проекты pascal очень близки по своей структуре к C++. В них включенные в проект файлы определяются файлом системы сборки, там же указываются дополнительные зависимости, параметры. В Pascal так же активно применяется препроцессор (не такой функциональный как c++, но так же влияющий на поведение кода, его разбор, анализ и рефакторинг).
Сейчас вы активно развиваете проектную модель и я хотел бы спросить — попадут ли эти наработки в основную IDEA и станут ли доступны для написания языковых плагинов к языкам с похожим поведением? Конкретно — построение структуры проекта из условной сборочной системы и обслуживание препроцессора?
Существует разрабатываемый энтузиастами плагин для IDEA I-Pascal, для поддержки языка pascal соответственно. При этом он строится на проектной (модульной) модели IDEA. Но на самом деле проекты pascal очень близки по своей структуре к C++. В них включенные в проект файлы определяются файлом системы сборки, там же указываются дополнительные зависимости, параметры. В Pascal так же активно применяется препроцессор (не такой функциональный как c++, но так же влияющий на поведение кода, его разбор, анализ и рефакторинг).
Сейчас вы активно развиваете проектную модель и я хотел бы спросить — попадут ли эти наработки в основную IDEA и станут ли доступны для написания языковых плагинов к языкам с похожим поведением? Конкретно — построение структуры проекта из условной сборочной системы и обслуживание препроцессора?
Пока не знаю, что Вам ответить. Это две разные задачи — сделать API для проектных моделей в CLion и перенести его в IntelliJ IDEA (тут просто исторически CLion отдельно развивается, поэтому это не просто). Но если, например, делать плагин из CLion к IntelliJ IDEA, то придется в любом случае переносить. Так что есть такая вероятность. А вот каких-то оценок по времени скорее нет.
Я правильно понимаю, что CLion функциональность не доступна из Idea в виде плагина (т.е. ситуация ближе к .NET/Rider чем, например к go/javascript?).
CLion действительно существует только как отдельная IDE, а как плагин — нет. Это не то, чтобы принципиальная позиция. Просто так сложилось исторически, а сейчас кажется не самой приоритетной задачей, при том, что технических вопросов/сложностей там много, а ресурсы ограничены.
Позиция понятна и мне кажется разумной. Пусть уж лучше будет один хороший продукт для работы с C++ чем два плохеньких. Просто хотелось уточнить. Спасибо за ответ.
Кстати еще вопрос. Последний раз когда пробовал что-то делать с Arduiono в Clion — интеграция была слабовато. Есть ли это направление в каких-нибудь roadmaps?
Кстати еще вопрос. Последний раз когда пробовал что-то делать с Arduiono в Clion — интеграция была слабовато. Есть ли это направление в каких-нибудь roadmaps?
Embedded направление достаточно приоритетно. Но конкретных задач пока не поставлено, там сначала надо решить пачку общих задач по отладчику: memory view сделать (он в процессе), hex view переделать (текущее решение нам не очень нравится и потому по умолчанию не включено), и тп.
Люди вроде пользуются Platform.io вполне успешно для Arduino + CLion. Там есть некоторая интеграция.
Люди вроде пользуются Platform.io вполне успешно для Arduino + CLion. Там есть некоторая интеграция.
Существует средний-большой проект с многими десятками Makefiles, вызывающие друг-друга и с десятками способов/параметров как его строить на все случаи жизни. Менять их на Cmake никто не собирается, т.к. все работает, а Cmake у нас никто не знает.
Импортирую новый не-Cmake проект, как советует документация, создается cmakelists; попробовал также compilation database. В обоих случаях все вроде работает (ок, не могу скомпилировать изнутри, пишу руками «make ...» в шеле, переживу, потом добавлю макро). Рефакторинг и навигация вроде работают, и уже хорошо. Довольный иду домой.
На следующий день обновляем репу и видим, что коллеги за ночь добавили Х новых директорий и файлов с кодом. В уже созданный cmakelists они сами не попадают и clion начинает грязно ругатся на код который иx использует, не находит новые инклюды итд.
(Вроде в 2018.2 хотя-бы инклюды вроде должны были работать? Или только из уже известных директорий?)
Как вы предлагаете работать в таком случае?
После каждого git pull импортировать проект с начала, стирая старый cmakelists?
Вручную добавлять новые директории каждый раз, выискивя их по одной?
Всегда гнатъ make с генерацией новой compilation database и опять открывать по-новой?
Вы понимаете, что все эти методы не масштабируются и уважающие свое время люди не будут это все время делать?
Я пропустил какой-то метод работы с такими проектами, который все таки оправдает переход на clion?
Если способ есть, рекомендую подробно описать его в доках, т.к. терпение и время находить его самим есть не у всех. Я, например, пока что плюнул и вернулся к бесплатному эклипсу, который сам находит все изменения (у эклипса свои проблемы, конечно).
Импортирую новый не-Cmake проект, как советует документация, создается cmakelists; попробовал также compilation database. В обоих случаях все вроде работает (ок, не могу скомпилировать изнутри, пишу руками «make ...» в шеле, переживу, потом добавлю макро). Рефакторинг и навигация вроде работают, и уже хорошо. Довольный иду домой.
На следующий день обновляем репу и видим, что коллеги за ночь добавили Х новых директорий и файлов с кодом. В уже созданный cmakelists они сами не попадают и clion начинает грязно ругатся на код который иx использует, не находит новые инклюды итд.
(Вроде в 2018.2 хотя-бы инклюды вроде должны были работать? Или только из уже известных директорий?)
Как вы предлагаете работать в таком случае?
После каждого git pull импортировать проект с начала, стирая старый cmakelists?
Вручную добавлять новые директории каждый раз, выискивя их по одной?
Всегда гнатъ make с генерацией новой compilation database и опять открывать по-новой?
Вы понимаете, что все эти методы не масштабируются и уважающие свое время люди не будут это все время делать?
Я пропустил какой-то метод работы с такими проектами, который все таки оправдает переход на clion?
Если способ есть, рекомендую подробно описать его в доках, т.к. терпение и время находить его самим есть не у всех. Я, например, пока что плюнул и вернулся к бесплатному эклипсу, который сам находит все изменения (у эклипса свои проблемы, конечно).
Я пропустил какой-то метод работы с такими проектами, который все таки оправдает переход на clion?Да, пропустили. Потому что это не в CLion'е должно быть.
У нас, к примеру, вообще своя собственная распределённая система сборки. Нужно было всего лишь научить её порождать CMake-проекты и поддерживать их и всё. Но это только вы можете сделать.
Если у вас Makefiles вообще без всяких ограничений, то это, строго говоря, не делается в принципе: Makefile в принципе не даёт ответа на простой вопрос «а какие, собственно, файлы входят в ваш проект».
Но в это я не верю. Обычно в проекте есть какая-то дисциплина, которая позволяет сделать соотвествующий конвертор.
А вообще, похоже, CMake — это будущее. Уже и Visual Studio с ними научился работать и даже поверх них свою систему управления пакетами получил и всякие проекты нативно его поддерживают. Так что учить придётся.
Мне лично немного грустно, так как CMake — тот ещё кусок… добра. Но лучше уже CMake через разброд и шатание, когда в каждом проекте своя система сборки.
Я, например, пока что плюнул и вернулся к бесплатному эклипсу, который сам находит все изменения (у эклипса свои проблемы, конечно).К эклипсу у нас тоже плагин, так как его способность находить изменения… ограничена, да…
Все верно, но «все работает и так», значит пока менять систему сборки никто не будет. Мой вопрос был с позиции, что такой раскад — аксиома, и в данном проекте не меняется.
Я не говорил, что согласен с этим — но тут так заведено ©.
Makefiles вполне (иногда — на основании параметров командной строки) определяют какие файлы когда использовать для билда, а также из какой суб-директории брать версию под конкретную железку.
И я не говорил, что эклипс все правильно парсит — но он смотрит, как я понимаю, на все дерево и пытается резолвить из всех файлов вообще.
Я не говорил, что согласен с этим — но тут так заведено ©.
Makefiles вполне (иногда — на основании параметров командной строки) определяют какие файлы когда использовать для билда, а также из какой суб-директории брать версию под конкретную железку.
И я не говорил, что эклипс все правильно парсит — но он смотрит, как я понимаю, на все дерево и пытается резолвить из всех файлов вообще.
И я не говорил, что эклипс все правильно парсит — но он смотрит, как я понимаю, на все дерево и пытается резолвить из всех файлов вообще.Правильно. Но в нашем случае он пытается затащить себе все исходники всего-всего-всего, несколько часов грузит всё это, сжирает 64GB оперативки и умирает.
Так что в любом случае нужен плагин.
Начнем с вводной, что CLion для работы всегда нужна хоть какая-то проектная модель, описывающая проектные файлы, связи между ними, флаги там всякие и пр. Вся эта информация нужна для резолва. Поэтому в целом, конечно, ситуация, что используется проектная модель А, а для CLion из нее генерируется проектная модель B, и при этом другие члены команды в проектную модель А часто вносят значительные изменения она не самая удобная. В проект ведь могли добавить каких-то новых файлов, никак не связанных и не используемых в предыдущих, новых флагов, и пр. и IDE надо об этом как-то узнать. То есть такие изменения должны отразиться в проектной модели B.
Теперь больше конкретики по вопросам:
Если новые директории попали под project root и если новые файлы включены в старые (которые уже расцененные CLion-ом как проектные) файлы посредством директивы include, то новые файлы будут расценены как проектные автоматически. Все должно работать в такой ситуации. Если это не так — это бага, пишите тикет в наш трекер. Мы вот только что попробовали у тебя добавить новую директорию с файлами под project root — все заработало и для CMake, и для compilation database.
Compilation database при этом кажется более легко поддерживаемым и точным способом получения допустимой CLion-ом проектной модели, чем Import Project, который генерирует CMake проект. Мы к тому же думаем, как инкрементальный аптейт в его случае ускорить.
Теперь больше конкретики по вопросам:
На следующий день обновляем репу и видим, что коллеги за ночь добавили Х новых директорий и файлов с кодом. В уже созданный cmakelists они сами не попадают и clion начинает грязно ругатся на код который иx использует, не находит новые инклюды итд.
(Вроде в 2018.2 хотя-бы инклюды вроде должны были работать? Или только из уже известных директорий?)
Если новые директории попали под project root и если новые файлы включены в старые (которые уже расцененные CLion-ом как проектные) файлы посредством директивы include, то новые файлы будут расценены как проектные автоматически. Все должно работать в такой ситуации. Если это не так — это бага, пишите тикет в наш трекер. Мы вот только что попробовали у тебя добавить новую директорию с файлами под project root — все заработало и для CMake, и для compilation database.
Compilation database при этом кажется более легко поддерживаемым и точным способом получения допустимой CLion-ом проектной модели, чем Import Project, который генерирует CMake проект. Мы к тому же думаем, как инкрементальный аптейт в его случае ускорить.
Спасибо за ответ, попробую в следущий раз отловить больше подробностей.
Вопрос о теории авто-резолва:
Если начали с:
project123
....src
........dir1
............file11.c
............file11.h
Это попало в CLion.
Потом репа обновилась до:
project123
....src
........dir1
............file11.c
............file11.h
............file12.c
............file12.h
.......dir2
............file21.c
............file21.h
Также старый file11.c заинклюдил новые file12.h и ../dir2/file22.h
Как я понимаю, все 3 .h файла найдутся и распарсятся? или file21.h не найдут, ибо из неизвестной директории?
А как насчет новых file12.c и dir2/file21.c?
dir2 не под project root, а глубже — значит его содержимое без моей помощи (или нового Compilation database) никогда не найдут?
Мне кажется, поиск новых директорий и файлов должен быть рекурсивным всюду, а не только из project root. Есть причины так не делать?
(можно добавить диалог со списком ново-найденного, где можно выбрать что взять в проект, а что выкинуть; результат выбора где-то запомнить, чтоб не спрашивать в следующий раз; я не утверждаю, что это легко хорошо сделать :-))
Compilation database при этом кажется более легко поддерживаемым и точным способом получения допустимой CLion-ом проектной модели, чем Import Project, который генерирует CMake проект. Мы к тому же думаем, как инкрементальный аптейт в его случае ускорить.т.е. вы да предлагаете
Всегда гнать make с генерацией новой compilation database и опять открывать по-новой?Попробую понятъ или так можно работать постоянно…
Вопрос о теории авто-резолва:
Если начали с:
project123
....src
........dir1
............file11.c
............file11.h
Это попало в CLion.
Потом репа обновилась до:
project123
....src
........dir1
............file11.c
............file11.h
............file12.c
............file12.h
.......dir2
............file21.c
............file21.h
Также старый file11.c заинклюдил новые file12.h и ../dir2/file22.h
Как я понимаю, все 3 .h файла найдутся и распарсятся? или file21.h не найдут, ибо из неизвестной директории?
А как насчет новых file12.c и dir2/file21.c?
dir2 не под project root, а глубже — значит его содержимое без моей помощи (или нового Compilation database) никогда не найдут?
Мне кажется, поиск новых директорий и файлов должен быть рекурсивным всюду, а не только из project root. Есть причины так не делать?
(можно добавить диалог со списком ново-найденного, где можно выбрать что взять в проект, а что выкинуть; результат выбора где-то запомнить, чтоб не спрашивать в следующий раз; я не утверждаю, что это легко хорошо сделать :-))
Поиск, конечно, рекурсивный, по файлам в дереве под project root. Все должно находиться в вашем случае.
Не найдутся те файлы, которые за пределами дерева под project root. Это как раз специально, чтобы не лезть с рефакторингами во всякие библиотеки, которые где-то сбоку проекта лежат.
Не найдутся те файлы, которые за пределами дерева под project root. Это как раз специально, чтобы не лезть с рефакторингами во всякие библиотеки, которые где-то сбоку проекта лежат.
Согласен.
Проверю, у меня сложилось впечатление, что именно в похожем случае не нашлись новые файлы овсем. Если повторю, открою баг.
Спасибо!
Проверю, у меня сложилось впечатление, что именно в похожем случае не нашлись новые файлы овсем. Если повторю, открою баг.
Спасибо!
Хорошо бы пример нам показать. Может, я что-то упускаю в вашей конфигурации.
Без проблем, как только индусы коллеги накоммитят еще, проверим. Возможно я ошибся, или не дождался пока все распарсится в тот раз.
Файле никакие прислать не смогу, все секретно. Но если удастся повторить на синтетическом примере — пожалуйста.
Другой вопрос: сделал Compilation database для двух разных проектов. Оба открылись в CLion, но в одном все файлы показаны, как в оригинальном дереве (как надо), а в другом — все в одном длинном однородном списке (== невозможно ориентироватся и не понятно как и где потом можно создавать новые).
В обоих проектах файлы сидят в похожих, достаточно глубоких структурах директорий (т.е. принципиальную разницу не вижу).
Думаю, виноваты разные стили Makefiles (а не CLion). Есть идеи на что где смотреть, чтобы это починить? Я пропустил какую-то опцию CLion чтоб он сам файлы как-то рассортировал по path?
Файле никакие прислать не смогу, все секретно. Но если удастся повторить на синтетическом примере — пожалуйста.
Другой вопрос: сделал Compilation database для двух разных проектов. Оба открылись в CLion, но в одном все файлы показаны, как в оригинальном дереве (как надо), а в другом — все в одном длинном однородном списке (== невозможно ориентироватся и не понятно как и где потом можно создавать новые).
В обоих проектах файлы сидят в похожих, достаточно глубоких структурах директорий (т.е. принципиальную разницу не вижу).
Думаю, виноваты разные стили Makefiles (а не CLion). Есть идеи на что где смотреть, чтобы это починить? Я пропустил какую-то опцию CLion чтоб он сам файлы как-то рассортировал по path?
Попробуйте изменить project root.
Например,
Если у меня структура:
папка 1
… файлы проекта
… папка 2
........compilation database
и файлы проекта в папке 1, а json файл, который я открываю в папке 2, то все файлы окажутся в одном длинном списке и CLion будет считать именно папку 2 (где лежит compilation database файл) проектным рутом. Tools | Compilation Database | Change project root, указываем папку 1 и наступает счастье.
Похоже на ваш случай?
Например,
Если у меня структура:
папка 1
… файлы проекта
… папка 2
........compilation database
и файлы проекта в папке 1, а json файл, который я открываю в папке 2, то все файлы окажутся в одном длинном списке и CLion будет считать именно папку 2 (где лежит compilation database файл) проектным рутом. Tools | Compilation Database | Change project root, указываем папку 1 и наступает счастье.
Похоже на ваш случай?
Кстати, тут наш технический писатель, отчасти по мотивам этого треда, написала вот такой полезный пример: www.jetbrains.com/help/clion/using-file-watchers.html#CompDBExample
Да, полезно, рекомендую всем. Еще появилась подробная статья (на английском) про работу с Makefile проектами при помощи Compilation Database:
blog.jetbrains.com/clion/2018/08/working-with-makefiles-in-clion-using-compilation-db.
Что-бы строить проект, добавляем External Tool с, в котором даем командную строку нашего make, добавляем туда Output Filter, чтобы ошибки подчеркивались (и по ним можно было переходить на нужную строчку в файле с ошибкой), уговариваем наш компилятор выдавать ошибки с полным путем до файлов (например, "-fdiagnostics-absolute-paths" для clang), т.к. при дефолтном относительном пути CLion [пока?] не может найти их сам (https://youtrack.jetbrains.com/issue/IDEA-197135), если проект на Compilation Database.
Теперь, если не забывать делать ״Tools->Compilation Database>Reload Compilation Database Project״ при каждом значительмом изменении структуры проекта, уже можно работать.
Возможно не помешает статья с переводом той статьи на русский (можно даже с моими добавками про External Tool выше) — если кого-то еще это интересует.
blog.jetbrains.com/clion/2018/08/working-with-makefiles-in-clion-using-compilation-db.
Что-бы строить проект, добавляем External Tool с, в котором даем командную строку нашего make, добавляем туда Output Filter, чтобы ошибки подчеркивались (и по ним можно было переходить на нужную строчку в файле с ошибкой), уговариваем наш компилятор выдавать ошибки с полным путем до файлов (например, "-fdiagnostics-absolute-paths" для clang), т.к. при дефолтном относительном пути CLion [пока?] не может найти их сам (https://youtrack.jetbrains.com/issue/IDEA-197135), если проект на Compilation Database.
Теперь, если не забывать делать ״Tools->Compilation Database>Reload Compilation Database Project״ при каждом значительмом изменении структуры проекта, уже можно работать.
Возможно не помешает статья с переводом той статьи на русский (можно даже с моими добавками про External Tool выше) — если кого-то еще это интересует.
Нет в жизни счастья, с одной стороны clion с rust плагином, с другой qt creator с поддержкой .ui файлов, qt документации и стилей из clang-format
Кстати про Rust обновление мы отдельный пост написали.
В смысле именно по Qt встроенная документация?
Это мы давно планируем сделать. Может, в 2018.3 что-то успеем.
qt документации
В смысле именно по Qt встроенная документация?
стилей из clang-format
Это мы давно планируем сделать. Может, в 2018.3 что-то успеем.
В смысле именно по Qt встроенная документация?
Да, документация пример которой можно увидеть здесь: http://doc.qt.io/
Поставляется с Qt (для linux часто отдельным пакетом), ее можно посмотреть
либо в отдельном приложении (Qt assistant) или просто нажав F1 на классе в Qt Creator.
Ага, поняла. Согласна, было бы удобно. Даже вот такая общая задачка под это есть в трекере, но руки пока не дошли.
Странно, после апдейта Pycharm и Clion видят проект из python и c файлов как одно целое, что ведёт к незначительным ошибкам. Ну и набор вкладок для редакторов теперь один, что очень неудобно.
Не очень поняла, если честно, что имеется в виду. Можно чуть поподробнее?
А это на самом деле один проект?
Можно скриншот приложить? Я, к сожалению, не очень поняла, про какие вкладки речь.
проект из python и c файлов как одно целое
А это на самом деле один проект?
набор вкладок для редакторов теперь один
Можно скриншот приложить? Я, к сожалению, не очень поняла, про какие вкладки речь.
Да, я несколько сумбурно объяснил: у меня один проект содержит C и Python код в одной директории. Теперь, когда я открываю Pycharm, я получаю:
Вдобавок, если открыть несколько файлов в соответствующем редакторе, например, main.c в Clion, а потом закрыть сам редактор и открыть тот же проект в Pycharm, то я снова получу main.c. Раньше я мог работать отдельно с .py и .c файлами, а теперь получается каша. Я не профессиональный программист и не работаю с IDE ежедневно, так что могу что-то упускать.
Cannot determine module type («CPP_MODULE») for the following module:
Вдобавок, если открыть несколько файлов в соответствующем редакторе, например, main.c в Clion, а потом закрыть сам редактор и открыть тот же проект в Pycharm, то я снова получу main.c. Раньше я мог работать отдельно с .py и .c файлами, а теперь получается каша. Я не профессиональный программист и не работаю с IDE ежедневно, так что могу что-то упускать.
Не подскажете, а есть ли вариант в CLion полностью отключить уведомления о том, что в коде есть какие-то ошибки, но оставив при это автодополнение, переход к обьявлениям функций и так далее? просто чтобы в IDE красным цветом не выделялось то, что парсер не смог распарсить (конечно я понимаю, что в данном случае часть невалидного кода тоже перестанет подсвечиваться красным). Причина — слишком большое количество красного кода на моём проекте.
Sign up to leave a comment.
Все, что вы давно просили, в одном релизе — CLion 2018.2