Comments 60
Планов нет или все-таки не решена бизнес-модель что продать из инструмента CLion.
Предлагаю убрать:
- поддержку всех видов Make(GNU autotools, GNU make, meson, CMake, etc.);
- поддержку проектов Visual Studio(если была);
- perf;
- clangd;
- удаленную разработку;
Ограничить: настройки как это сделано в Intelij IDEA и PyCharm (соответствующих редакций);
Это и будет Community Edition для CLion.
P. S. И никаких веских причин кроме экономических не надо. Будем честны перед потребителями.
Плюс с потребителей Community Edition берите деньгу за техподдержку и доступ к специальному репозиторию необходимого функционала.
Мы не берем деньги за техподдержку принципиально.
Рад, что JetBrains принципиальна.
А без того же clangd поддержка языка очень страдает.
Для комьюнити версии нейтрализация clangd не вызовет особых страданий у потребителей ведь не всегда им нужен code completion. (Да, я отчасти не всегда на стороне потребителя.)
В общем, спасибо за предложение, но пока кажется, что это не релевантно.
Оно окажет отклик лишь после тестового введения комьюнити версии с опросом пользователей.
Тогда признаю вашу точку зрения на этот счет.
Хотя продолжу считать, что gcc -Wall -Werror -c -o /tmp/test.o $@; rm -f /tmp/test.o
лучше запуска отдельного демона процедуры компиляции. (Хотя суть действия не меняется исключая конечно появление всех ошибок и предупреждений как ошибка на этапах до линковки.)
Как 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.
У меня есть две основные претензии к CLion:
- Он так и не научился Ninja. Даже с CMake.
- В нем нет нормального хоткея переключиться .h/.cpp. Есть Go to Related symbol, который на больших проектах тормозит настолько, что быстрее ввести имя файла вручную...
- Ninja — не умеем, есть технические причины, но планируем сделать (вероятно заработает, когда перейдем на CMake server). Просто руки не доходят.
- .h/.cpp переключение — тоже сделаем, надеюсь, уже в 19.1.
У меня в режиме Unix Makefiles сборка без изменений (по факту просто проверка что всё собрано) занимает около 5-7 секунд… С Ninja меньше секунды...
- Переключение h/cpp: ctrl+alt+home
- Можно уйти в навигацию по дереву: alt+home
Это описано в key map reference.
Go to related symbol делает именно то что в названии. Грубо говоря если курсор на обьявлении метода в хидере, то он перейдет в реализацию в соответствующем .cpp файле. Но если реализацию метода спрятать в абсолютно другом .cpp файле (с другим именем) то CLion его всё равно найдет там.
Это было бы не так важно, если бы не одно но. На больших проектах это очень медленно.
Есть локальная машина на которой идёт разработка, на ней все исходники, cmake, SDK целевой платформы. Целевая платформа это linux на ARM устройстве.
Проект собирается. Отлично. Проект можно руками перенести на целевую платформу, запустить под gdb сервером, создать конфигурацию удалённой отладки и ок, это в целом даже будет работать. Но это неудобно.
Хочется один раз настроить удалённую машину и получить синхронизацию. Собирать приложение сразу туда, запускать из среды разработки.
Может подобные сценарии будут рассматриваться в рамках вашей работы под Embedded?
Или ещё более сложные, например разработка под WSL и отладка на железе?
Но когда надо собраться на одной машине, а отладиться на другой — надо сделать большое количество действий руками: перенести собранную программу, запустить gdb сервер, подключиться к серверу из Clion.
Ошибка, падение,… — руками перезапускать gdb сервер. Изменение — руками переносить собранный файл.
В моём случае железо это почти обычный Linux. Просто на ARM. С обычным ssh и прочими радостями жизни. Но ресурсов железа не хватит чтоб прям там собирать программу и пользоваться возможностью удалённой разработки. Нужна именно простая удалённая отладка. То есть грубо говоря rsync бинарника и запуск gdb сервера через ssh.
И WSL мне нужен как среда разработки но не как среда отладки. Из WSL мне всё равно надо будет скопировать приложение на целевое устройство, запустить gdb сервер и далее по пунктам.
Сейчас два пути развития — есть CLion и есть возможность получить CMake проект прямо из UE4 редактора, там с 4.20 CLion/CMake генерация проекта есть встроенная. В CLion дальше есть прикольный плагин для комплишена рефлекшен спецификаторов.
Ну и мы планируем в Rider иметь специальную поддержку для C++/Unreal Engine случая, тулчейн MSVC/msbuild.
Ну и про удаленную отладку в Rider: blog.jetbrains.com/dotnet/2018/11/29/remote-debugging-comes-rider-2018-3
CLion 2018.3: удаленная разработка, профилирование кода, быстродействие и не только