Как стать автором
Обновить

Комментарии 60

Ребяяяяяяят, ну дайте уже Community Edition пжлста.
Вынуждена разочаровать — пока таких планов у нас нет.
Жаль конечно, но всё равно мы все очень любим ваши инструменты!!!
Спасибо за поддержку!
Для любых наших IDE есть вариант, как платить не ноль, но очень мало: сидите на ЕАПах, а в те месяцы, когда их нет – покупайте месячную подписку. Итого это выйдет примерно три (ну, окей, четыре) платных месяца в год. Получается, 48 долларов в год, то есть 250 рублей в месяц :) Точно так уж нужна комьюнити?

Летом тут за те же ~45 баксов раздавали годичную лицензию.

Ну да, или скидки ловить.
Что такое ЕАП?
Early Access Program — превью будущих версий. Нестабильные, но бесплатные билды, которые можно качать с сайта и пробовать последние изменения.
Можно узнать причины?
Чтобы делать коммьюнити версию нужны веские причины и обстоятельства, мы их пока не видим в случае CLion/C++.

Планов нет или все-таки не решена бизнес-модель что продать из инструмента CLion.
Предлагаю убрать:


  1. поддержку всех видов Make(GNU autotools, GNU make, meson, CMake, etc.);
  2. поддержку проектов Visual Studio(если была);
  3. perf;
  4. clangd;
  5. удаленную разработку;

Ограничить: настройки как это сделано в Intelij IDEA и PyCharm (соответствующих редакций);


Это и будет Community Edition для CLion.
P. S. И никаких веских причин кроме экономических не надо. Будем честны перед потребителями.
Плюс с потребителей Community Edition берите деньгу за техподдержку и доступ к специальному репозиторию необходимого функционала.

Мы не берем деньги за техподдержку принципиально. А без того же clangd поддержка языка очень страдает. В общем, спасибо за предложение, но пока кажется, что это не релевантно.
Мы не берем деньги за техподдержку принципиально.

Рад, что JetBrains принципиальна.


А без того же clangd поддержка языка очень страдает.

Для комьюнити версии нейтрализация clangd не вызовет особых страданий у потребителей ведь не всегда им нужен code completion. (Да, я отчасти не всегда на стороне потребителя.)


В общем, спасибо за предложение, но пока кажется, что это не релевантно.

Оно окажет отклик лишь после тестового введения комьюнити версии с опросом пользователей.

Я не соглашусь про clangd — он сейчас используется для показа ошибок и предупреждений, и сильно помогает особенно в случае использования фич языковых, которые не поддерживает наш собственной движок пока. Ну и мы в целом планируем попробовать довольно много фич в будущем перевести на clangd (где это возможно).

Тогда признаю вашу точку зрения на этот счет.
Хотя продолжу считать, что gcc -Wall -Werror -c -o /tmp/test.o $@; rm -f /tmp/test.o лучше запуска отдельного демона процедуры компиляции. (Хотя суть действия не меняется исключая конечно появление всех ошибок и предупреждений как ошибка на этапах до линковки.)

видимо очень сложно разделить функционал, как для java разработчиков.
А есть ли в этом смысл вообще? Неужели вариант с покупкой лицензии под коммерческую разработку и бесплатным использованием для pet проектов недостаточно выгодный?
Мне кажется этот вариант был бы очень крутой!
Как VS Community Edition, они и для коммерческой лицензии разрешают пользоваться, но очень небольшим компаниям.
Если бы у CLion была бы лицензия OpenSource — бесплатно, остальное платно — рынок был бы их полностью.
Спасибо, это известная информация.
Но там слишком много «если»…
Хотя компания может и не давать ничего, так что это в любом случае лучше чем ничего!

You have to be a project lead or a regular committer.
Your OS project meets the Open Source definition.
Your OS project may not offer paid sponsorship, or receive funding from commercial companies or organizations (NGO, education, research, or governmental). You may not provide any paid support, consulting or training services for your OS project, and you may not distribute paid versions of your OS software. Contributors who are paid to work on the project are not eligible.
Your OS project is in active development for a minimum of 3 months.
Your OS project's community is active.
You release updated builds on a regular basis.
«Если» много, но все они имеют причины. Если Вам кажется, что вы не до конца удовлетворяете условиям или не уверены в чем-то, но все равно хотели бы получить лицензию для разработки OS проекта, стоит написать на sales@jetbrains.com, мы попробуем разобраться с Вашим конкретным случаем в частном порядке.
НЛО прилетело и опубликовало эту надпись здесь
CLion умеет не только CMake. Есть еще compilation database, которую можно сгенерировать из почти всего.

Но вопрос, конечно, разумный. И ответ — да, появится. Мы как раз в процессе выделения API. Надеюсь, в следующем году будет версия, которой можно будет пользоваться.
НЛО прилетело и опубликовало эту надпись здесь

У меня есть две основные претензии к CLion:


  • Он так и не научился Ninja. Даже с CMake.
  • В нем нет нормального хоткея переключиться .h/.cpp. Есть Go to Related symbol, который на больших проектах тормозит настолько, что быстрее ввести имя файла вручную...
  • Ninja — не умеем, есть технические причины, но планируем сделать (вероятно заработает, когда перейдем на CMake server). Просто руки не доходят.
  • .h/.cpp переключение — тоже сделаем, надеюсь, уже в 19.1.

У меня в режиме Unix Makefiles сборка без изменений (по факту просто проверка что всё собрано) занимает около 5-7 секунд… С Ninja меньше секунды...

С тем, что Ninja генератор быстрее Makefiles, мы не спорим. Это безусловно так. Сложности там именно в поддержки формата в CLion. Решаемые, но требуют доп.ресурсов, которые пока заняты другим.

Спасибо!

У меня в CLion это есть. Попробуйте:
  1. Переключение h/cpp: ctrl+alt+home
  2. Можно уйти в навигацию по дереву: alt+home

Это описано в key map reference.
ctrl+alt+home — это и есть Go to Related Symbol. Но он действительно не всегда навигирует туда, куда хочется. В основном, потому что это платформенное действие, а надо реализовать именно действие со спецификой C++. Мы планируем это сделать. Именно в формате добавить отдельное действие навигации для переключения между заголовочным файлом и сорс.

Go to related symbol делает именно то что в названии. Грубо говоря если курсор на обьявлении метода в хидере, то он перейдет в реализацию в соответствующем .cpp файле. Но если реализацию метода спрятать в абсолютно другом .cpp файле (с другим именем) то CLion его всё равно найдет там.


Это было бы не так важно, если бы не одно но. На больших проектах это очень медленно.

Удаленная отладка, запуск, компиляция, которая по ssh — работает только с CMake. В Rust, полагаю, вы Cargo используете. Так что — пока нет.
А поддержки Ninja всё ещё нет?
Ну вот я выше ответила:
Ninja — не умеем, есть технические причины, но планируем сделать (вероятно заработает, когда перейдем на CMake server). Просто руки не доходят.
А поддержки Ninja всё ещё нет?
А я порадовался тому, что есть gradle c++ проекты, и оно всё быстро и из коробки завелось на виндовой машине, найдя локальную установку Visual Studio. Только жаль, что debug в нём не работает. Хотелось бы подвижек в этом направлении тоже, но, как я понимаю, тут ещё дело за самими gradle встало…
Отладчик для случая VS/MSVC планируется в следующем году. Мы его сами пишем, так как VS отладчик проприетарный.

Это что-то на базе cdb/windbg?

Нет, такой вариант мы пробовали, там возникло много проблем.
Сейчас делаем на базе LLDB.
Я смотрю приоритет отдался удалённой разработке, а как идут дела в вопросах удалённой отладки, удалённого профилирования и т.д.?
Есть локальная машина на которой идёт разработка, на ней все исходники, cmake, SDK целевой платформы. Целевая платформа это linux на ARM устройстве.
Проект собирается. Отлично. Проект можно руками перенести на целевую платформу, запустить под gdb сервером, создать конфигурацию удалённой отладки и ок, это в целом даже будет работать. Но это неудобно.
Хочется один раз настроить удалённую машину и получить синхронизацию. Собирать приложение сразу туда, запускать из среды разработки.
Может подобные сценарии будут рассматриваться в рамках вашей работы под Embedded?
Или ещё более сложные, например разработка под WSL и отладка на железе?
Не очень поняла, наверное, но WSL поддержан уже. Сборка/запуск из CLion сразу на удаленной машине — тоже. Отладка на железе — в планах, соб-но, про них и речь в конце.
Сейчас в CLion можно собраться и отладиться без проблем в рамках одной машины (локальной или удалённой). Это хорошо и здорово.
Но когда надо собраться на одной машине, а отладиться на другой — надо сделать большое количество действий руками: перенести собранную программу, запустить gdb сервер, подключиться к серверу из Clion.
Ошибка, падение,… — руками перезапускать gdb сервер. Изменение — руками переносить собранный файл.
В моём случае железо это почти обычный Linux. Просто на ARM. С обычным ssh и прочими радостями жизни. Но ресурсов железа не хватит чтоб прям там собирать программу и пользоваться возможностью удалённой разработки. Нужна именно простая удалённая отладка. То есть грубо говоря rsync бинарника и запуск gdb сервера через ssh.
И WSL мне нужен как среда разработки но не как среда отладки. Из WSL мне всё равно надо будет скопировать приложение на целевое устройство, запустить gdb сервер и далее по пунктам.
А, поняла, спасибо! Это CPP-7050. Мы его планируем в следующем году сделать.
Когда уже будет нормальная поддержка для Unreal Engine 4? Очень хочу уйти со студии (Любитель Rider, WebStorm, Intellij idea)
А что именно хочется?
Сейчас два пути развития — есть CLion и есть возможность получить CMake проект прямо из UE4 редактора, там с 4.20 CLion/CMake генерация проекта есть встроенная. В CLion дальше есть прикольный плагин для комплишена рефлекшен спецификаторов.
Ну и мы планируем в Rider иметь специальную поддержку для C++/Unreal Engine случая, тулчейн MSVC/msbuild.
Вот как раз специализированный плагин для поддержки UE4 у меня и не работает… Встраивание поддержки с++ в Rider? Это конечно круто, но почему тогда CLion и Rider изначально не объединили, подобно Visual Studio? Я также много работаю на C# и мне очень нравится Rider. Пожалуй единственное, в чем он сейчас уступает студии — это удаленная отладка. Радует, что работы в направлении поддержки UE4 ведутся:)
А как именно не работает? fsmorygo наверное может помочь, он автор)
Касательно вопроса про CLion/Rider, там длинная история, но по факту CLion вообще скорее ориентирован на кросс-платофрменную разработку и никакой поддержки Windows специфики и msbuild/MSVC тулчейна в нем никогда не планировали, а вот в Rider все иначе — там как раз легко поддержать UE4 разработку, которая в основном именно в таком окружении происходит.

Ну и про удаленную отладку в Rider: blog.jetbrains.com/dotnet/2018/11/29/remote-debugging-comes-rider-2018-3
Ну и про удаленную отладку в Rider...
оО Крутяк! Спасибо
А можно поинтересоваться, чем определяется очередность исправления ошибок? Вот уже пять месяцев без движения висит CPP-13456, который намертво завешивает IDE.
Частотой воспроизведения случая, количеством репортов, сложностью фикса, планами по более глобальным переделкам каких-то подсистем связанных. Мы посмотрим, что там за проблема. Спасибо за напоминание.
Ребята, когда добавите нормальную поддержку IAR toolchain, не покупаем только из-за кривой поддержки кроссплатформенных компиляторов, таких как IAR.
IAR toolchain сейчас не поддержан, так как не GCC-based. Но планируем его в рамках всяческих задач по embedded поддержке. Вероятно, в 2019.x каком-нибудь. Вот тут можно подписаться на обновления по задаче.

Спасибо, будет ждать.

2019.1 вышел на пробу, а так ничего и не поправлено. include_directories как не работал, так и не работает. Не могу пользоваться :(, уже бы 10 лицензий купили бы. А так только 2 попробовать и ждем…
Что значет include_directories не работает, поясните? Можно тикет дать в трекере.
Изначально вот этот:
CPP-10954
и
CPP-12576
вроде как ошибку компиляции убрали, но include_directories все равно игнорируется.
Ну и связанный с ним:
CPP-12788
При поддержку IAR тут:
CPP-1492
Зарегистрируйтесь на Хабре , чтобы оставить комментарий