Комментарии 22
У remote тулчейнов есть один нюанс, о котором нигде не написано:
Приложения, собранные этим тулчейном запускаются тоже в этом remote окружении и это никак нельзя изменить.
Почему это важно? Потому что на C++ пишется не только бэкенд, когда это в принципе оправдано, и при этом среда сборки не обязательно должна совпадать со средой выполнения.
И довольно легко иметь окружение в Docker, которое будет собирать полностью статичные бинарники (либо упаковывать разделяемые библиотеки вместе с приложением), но будет бесполезно для выполнения.
Например, это характерно для GUI приложений, игр и вообще всего что связано с выводом на экран.
В таком случае удобно иметь стабильное окружение для сборки в docker, но запускать локально.
Все так, хотя для игр это может тоже применяться. Мы рассматривали возможность запуска и отладки игровых клиентов на удаленных машинах когда начались локдауны.
У нас, кажется, в документации все же указано, что в удаленном режиме все удаленно и запускается.
Вообще для более сложных сетапов, когда сборка и запуск на разных машинах, есть общий подход, описанный тут. По сути, в случае запуска локально, там даже проще. Есть локальная конфигурация для запуска и удаленная для сборки. А также external tool настраиваете, чтобы скачивать бинарь с удаленной машины на локальную. Вроде должно норм работать.
Конкретно с докером никаких дополнительных телодвижений не нужно, по сути бинарь и все остальные артефакты сборки складываются в приаттаченный volume, т.е. в корень проекта (cmake-build-debug-xxx) и доступны для последующующего локального запуска. Можно создать локальную run-configuration у контрой убрать build-step, а в качестве executable указать бинарь собранный в докере.
То, что включили mingw в стандартную поставку - спасибо, доустановить ее не особая проблема, но все-таки мелкое неудобство, а как потом в него добавить библиотеки или, например интегрировать с QT?
Это хороший вопрос) Спасибо. Мы про него думали и видим, конечно, определенную сложность. Для QT можно установить официальный дистрибутив, указав в компонентах MinGW 64-bit, дальше сконфигурировать в CMake. CLion темплейты Qt проектов (console/gui) работают из коробки, если указать QT через CMAKE_PREFIX_PATH (по умолчанию MinGW 64-bit QT ставится в "C:/Qt/Qt5.12.12/5.12.12/mingw73_64").
В случаях других библиотек, там только через поиск библиотеки в CMake подключать. Но для тех, кто хочет побыстрее начать разработку в пустом окружении, бандленный mingw все равно перевешивает по удобству.
А где то есть почитать насколько все эти remote чувствительны к задержке, к примеру, клиент в Европе, сервер в США. Ну или даже банально лаптоп на WiFi с телефона? Возможно ли будет работать в таком сетапе?
В целом, JetBrains Client подразумевает редактор, работающий на основе протокола JetBrains Rider’s RD (это как раз протокол, который использует наш продукт Rider для общения с бэкендом из ReSharper-а). Этот протокол оптимизирован так, чтобы тайпинг ощущался мгновенным. Умная работа с кодом происходит на стороне сервера IntelliJ IDEA и организована так, чтобы ощущалась как локальный инстанс.
Но тут, конечно, многое зависит от сети. И при каких-то больших пингах, понятно, что комплишен будет не мгновенный, и вообще будет не прямо как локально. В целом, у нас в тестировании все работает адекватно. Но при этом работа ведется и по части оптимизации latency.
Использую с напарником режим remote для PyCharm и CLion. Первые впечатления конечно очень хорошие — идея и направление правильное. Но к сожалению, в процессе работы постоянно выскакивают всякие странности, например, клиент Gateway просто может зависнуть на всегда по не понятным мне причинам — иногда от открытия вкладки с файлом, иногда от дебага, а иногда при попытке использовать автодополнение и прочее. Спасает только диспетчер задач.
Пинг сильно мешает, по крайней мере мне. Если больше 100, то работать очень не комфортно, задержки страшные, даже по инпуту. Хорошо что в моем далеком городе есть более менее адекватный хостинг с пингом <10. У Visual Studio Code с этим лучше, по моим ощущениям. А еще на боевых проектах, CLion очень много кушает ресурсов.
Очень надеюсь на JetBrains Fleet. Если я правильно понял, там всё, включая remote, реализованы по другому.
Планируете ли добавить какой нибудь готовый шаблон проекта для embedded? Чтобы на его основе можно было модифицировать проект.
Либо например сделать как segger embedded studio, эта IDE позволяет в 2-3 клика импортировать проект из IAR/Eclipse. Это достаточно удобная вещь.
Шаблон для Embedded - очень расплывчатое понятие. Сейчас есть интеграция с STM32CubeMX проектами и с PlatformIO (если плагин поставить). Мы, конечно. хотели бы больше, но пока не понятно, что именно стоит сделать в первую очередь. Можете привести примеры, какие конкретно проекты еще хочется видеть?
@Elmot может сможет что-то еще подсказать тут.
Можно например: Сделать шаблон под самую распространенную архитектуру и ядро (например Cortex M0). В main сделать цикл, который по достижении определенного числа что то вызывает. Собирать все это через GCC ARM (т.к. он бесплатный). Что то подобное было бы удобно для старта нового проекта. Т.к. все пути и настройки уже подтянуты. Дальше уже меняем абстрактный Cortex M0 на конкретный чип, тулчейн если надо, подтягиваем линкер файл, .svd и вперед.
У segger embedded studio примерно так и сделано.
Просто лично мне не очень понравилось как это сейчас реализовано у вас, возможно потому что с вашими IDE никогда не работал и чего то не понимаю. Но те же segger embedded studio, eclipse, IAR позволяют создать готовый шаблон, где то абстрактный, где то под конкретный чип/семейство.
В новой версии сломан дебаггер для моего проекта ещё начиная с первых EAP. Пока что решил для себя копией бинарей дебаггера от прошлой версии. Вроде как это баг в lldb, видел у вас на трекере. Что-то известно насчёт ETA?
Индексация кода очень заметно ускорилась - теперь 2021.2 кажется очень медленной на контрасте. К сожалению это также частенько показывает ложные предупреждения о неиспользуемых переменных
А есть описание того, как именно сломан дебагер? Или ссылка на тикет?
Аналогично про ложные срабатывания, есть тикет или пример?
С дебаггером описывать особо нечего - просто при попытке поставить на паузу процесс или поставить breakpoint в некоторых местах, происходит SIGSEGV в самом lldb. Ни в логах ни в окне ошибок IDE - ничего нет
С ложными срабатываниями - происходит не постоянно. Не уверен триггерится это при запуске или уже во время работы. Если найду какой-то более подходящий пример для воспроизведения - отпишусь.
P.S. падение при установке бряков есть и в 2021.2, но гораздо реже - только если попытаться поставить точку в темплейтной функции, которая встречается в 100+ модулей. Видимо зависит от количества локаций в бинаре, куда нужно поставить останов.
P.P.S
void Process(const Foo* global, size_t index,
size_t& containers) const override
{
containers = 0;
for (auto& cont: Containers)
{
size_t container;
cont.second->Process(container, nullptr);
containers += container;
}
}В этом участке сообщает, что containers и cont не используются
Про отладчик, нам неизвестны такие проблемы в версии LLDB, которая в релизе. Там был краш, но мы его откатили, и аналогично в LLVM его недавно тоже ревертнули, но он выглядел иначе. Можете собрать логи по этой инструкции, пожалуйста, и создать тикет в трекере, приложив логи и описание проблемы?
А вот падения, как вы описываете в 2021.2, похоже на то, что откатывали мы и LLVM. В общем, давайте разбираться с текущей проблемой на 2021.3, начнем с логов.
Спасибо за пример с ложным анализом. Сейчас посмотрим. У меня правда только container показывается как unused.
Релиз CLion 2021.3: новый механизм удаленной разработки, тулчейн для Docker, улучшения отладчика и многое другое