Pull to refresh

Comments 23

Давно хотел спросить.
Скажите, есть ли планы усовершенствовать используемую в Clion code-model так, чтоб препроцессорный код валидировался/препроцессировался и т.д?
А Вы не могли бы пример привести? Не очень понятен use case. И чего хочется.
Rust! Я хочу поддержки Rust! :)

Хотя и плюсы выглядят весьма вкусно. KDevelop (особенно 5 версия) — великолепный инструмент для анализа и написания кода. Вот только ему очень не хватает инструментов рефакторинга, которые есть в CLion.

Ребята вот делают плагин. Вероятно со временем его можно будет в CLion использовать (за сейчас не скажу, не уверена).
Первая IDE на которую я подумывал пересесть с vim. Мне не хватило возможности удаленного редактирования кода (когда сами сорцы лежат на удаленном сервере и сборка с запуском происходят там же).
Планируете запилить?
У нас есть плагин под названием Remote Host Access, который умеет синхронизировать сорцы:

Хочется сказать спасибо всей команде за организацию мероприятия. Мелкие недостатки в виде потерянных людей и очередями за кофе можно даже не учитывать :) Интересно было послушать про внутреннюю «кухню» разработки.

Отдельное спасибо Дмитрию за прекрасный, расширяющий сознание рассказ и байки про «сервер в подвале» :)
Спасибо! Мы рады, что вам понравилось.
А что там про потерянных людей было? Про внутреннюю кухню обязательно еще расскажем с удовольствием. У нас, например, есть в планах мысль поделиться тем, как DFA (Data Flow Analysis) в CLion сделан.
На входе часть людей не нашли в списках зарегистрированных (сам оказался таким), провели в итоге без проблем, но некую очередь на входе это создало :)

Будет интересно послушать. На самом деле при общении по CLion больше всего удивило, что они не пересекаются с ReSharper по кодовой базе, хотя, казалось бы, делают схожие вещи.

Жду следующего EAP по CLion :)
А вы когда регистрировались? Мы выгрузили списки на ресепшн в середине дня. Но регистрацию закрыли. Возможно, проблема была с этим связана.

Исторически, CLion основан на платформе IntelliJ, а ReSharper C++ на ReSharper-платформе. Поэтому, конечно, кодовая база разная. Но сейчас идет очень тесное общение командами, цель которого иметь одинаковый user experience в обоих инструментах. Рефакторинги, кодо-генерация, инспекции — все это должно по задумке работать примерно "одинаково".
Регистрировался в день анонса мероприятия на Хабре. Может быть "что-то пошло не так", бывает :) Например, на мероприятиях Softline людей часто теряют пачками, дело привычное :)
Причину "почему так" в деталях раскрывали на встрече, я помню. Просто сам факт был немного удивителен :)
Очень странно. Разузнаю, и попробуем исправиться) Спасибо.
Вам спасибо :) Больше встреч хороших и разных!
Коллеги, давно мечтаю использовать ваш продукт для работы над ядром операционной системы, но — всё никак. :( Скажите, есть ли какой-то шанс обойтись без cmake? Перетаскивать на него сборку трёхэтажной конструкции с библиотеками, шахматами и поэтессами — никакой мочи нет. Второй дурацкий вопрос — размеры шрифтов. Глаза уже не те, хочется пресет под крупные (18pt) шрифты. Если редактор ещё удаётся в этот режим загнать, то UI бастует. Звучит глупо, но это реально мешает жить. :(
Пока без CMake никак. Планируем делать и другие проектные модели, но пока руки не дошли.
Шрифт UI настраивается в Appearance & Behavior | Appearance — там можно переопределить дефолтовый шрифт и/или размер.
А как вы относитесь к способам вроде eax.me/clion-any-project?
Возможно, гораздо проще улучшить Import From Sources чтобы он начал использовать какую-то инофрмацию из других build-систем. Можно было бы даже попарсить запуски компиляторов, как это вроде делает eclipse. Собирать он, допусим, так не научится, а вот индексировать код должно быть проще.
Хорошо относимся)
Если серьезно, то такие варианты тоже рассматриваются. Там тоже есть определенные сложности.
Просто я ни разу не видел чтобы вы предлагали такой способ тем, кто жаловался на cmake. Не расстраивайте людей зря)
Когда мы говорим про API на проектную модель, это в общем оно и есть. Тут проблема в том, что просто запустить компилятор на файлах пользователя, этого не достаточно, чтобы правильно распарсить код.
На самом деле, в интернете есть скрипты, которые конвертируют разные форматы (например MSVC) в CMake. Я не ручаюсь за их качество, но они точно существуют. Другой вопрос — это синхронизация проектных моделей, тут может возникнуть некоторый дискомфорт.
А зачем синхронизировать? Надо брать и переезжать на CMake.
Ну в если серьёзно, то обратная синхронизация не всегда нужна, а разобраться с 3,5 командами CMake которые расскажут про то откуда брать и что определять должно быть не сложно, был бы каркас. Так что лично мне кажется это самым разумным костылём, и я был бы очень рад если бы односторонняя конвертация была бы поддержана CLion насколько это воможно, даже пусть потом у этого не работал бы configure и build.
На заметку, вот тут список каких-то скриптов для конвертации: https://cmake.org/Wiki/CMake#Converters_from_other_buildsystems_to_CMake
Да, спасибо за идею. Возможно, если текущий функционал Import Project будет уметь какие-то скрипты запускать такие, будет не плохо. надо подумать.
Хотя по личному опыту, реальный проект на Makefile-ах в CMake переводили человеко-месяц ручками и никакие скрипты там не помогли. Правда при этом существенно полечили проблемы проекта. Что было ценно само по себе..
Sign up to leave a comment.