У нас сегодня отличные новости — вышел очередной релиз нашей кросс-платорфменной среды для разработки на C и C++, CLion 2016.1.
Версия 2016.1
Вы, наверное, немного удивлены номером версии. Ближайшие релизы других наших десктопных инструментов, кстати, имеет такую же версию, начиная с IntelliJ IDEA 2016.1. В чем же смысл? Если коротко, то теперь все продукты в рамках пакета JetBrains All Products (то есть все десктопные инструменты) получают обновления примерно в одно и тоже время несколько раз в год. Таким образом, версия — это просто год и последовательный номер “пачки” релизов. Основные возможности, реализованные в платформе, попадают во все IDE одновременно, и такая унификация версий позволяет легче ориенироваться в платформенных изменениях.
Кроме того, мы решили отказаться от схемы выпуска мажорных-минорных релизов. Теперь каждый релиз нацелен на то, чтобы принести пользу как новыми возможностям, так и постоянными баг-фиксами и улучшениями производительности. Подробно о причинах перехода и самой новой схеме можно почитать в статье на англоязычном блоге компании.
А теперь — непосредственно о новых возможностях!
C++ парсер и улучшения по работе с кодом на C++
Долгое время CLion поддерживал C++11 с ограничениями: некорректно обрабатывались variadic templates, constexpr, user-defined литералы. В этой версии мы взялись за то, что, как нам показалось, “мешает” большинству наших пользователей — variadic templates. Код, подчеркнутый красным, некорректные нотификации от анализатора кода, неверное автодополнение и другие проблемы зачастую были связаны именно с этой возможностью C++11. Реализация variadic templates позволила закрыть порядка сотни багов в нашем трекере! В частности, спешим обрадовать пользователей Qt библиотеки — вызовы connect теперь обрабатываются корректно, а встроенный анализатор кода не предупреждает о некорректных типах:
Какие-то связанные проблемы все еще есть, но их уже значительно меньше. А если вдруг мы еще о чем-то не знаем, обязательно добавляете репорты в наш трекер.
Помимо прочего, мы наконец добились корректной работы автоматического импортирования для символов из STL (к сожалению, еще остаются проблемы при работе с MinGW-w64). Теперь, если соответствующий заголовочный файл не подключен, а символ уже используется, CLion предлагает добавить нужную директиву
#include:
Если в CLion поставить курсор на какой-нибудь символ и вызвать окно документации (
Ctrl+Q для Linux/Windows, F1 для OS X), можно посмотреть определение соответствующего символа и место, где он определен. В новой версии окно документации поддерживает гиперссылки на связанные топики, что существенно облегчает процесс чтения и понимания кода:
Отдельно упомянем новые возможности кодогенерации в коде на C++. Раньше для создания новых функций было две возможности — Override и Implement. Теперь появилась еще и Generate Definitions. Чем же они отличаются? По сути, мы выделили из Implement создание тела функции, а в Implement оставили только возможность генерации определения для чисто-виртуальных функций базовых классов. Новая функция доступна из меню генерации (
Alt+Insert на Windows/Linux, ?N на OS X), напрямую (Shift+Ctrl+D на Windows/Linux, ??D на OS X) и через intention actions (Alt+Enter):
Но главное даже не это. Самым важным улучшение является возможность генерировать функции in-place (не важно, через Override/Implement или через Generate Definitions), то есть там, где стоит курсор. Хотите получить тело функции в заголовочном файле — вызывайте функцию в соответствующем классе в этом заголовочном файле, хотите в .cpp файле — идите туда и вызывайте генерацию там. При наличии нескольких вариантов CLion уточнит, где именно вы хотите получить определение функции:
Управление директориями
CLion полагается на структуру проекта, которую задает CMake. То есть включены или не включены файлы в проект, где искать файлы из
#include директив и т. д. А что, если среди файлов, которые стоит иметь включенными в проект, находятся еще и файлы логов или артифакты сборки? Как объяснить CLion, что не надо тратить время на индексацию таких директорий? Или как исключить библиотеку из контекста, в котором работают рефакторинги (вряд ли вам хочется, чтобы рефакторинги повлияли на код библиотеки, который, хоть и лежит внутри вашего проекта, но все же является сторонним)?Для всех этих целей и реализована новая возможность Mark directory as:
Она дает возможность вручную разметить директории соответствующим образом. Выбор повлияет на работу:
- автодополнения и автоимпорта
- кодогенерации
- навигации на файл/класс/символ по его имени
- поиска по указанному пути
- рефакторингов
Так, например, рефакторинги и кодогенерация не будут работать в исключенных из проекта директориях (Excluded) или в библиотеках (Library Files). А навигация и поиск имеют специальные опции для отображения результатов поиска по библиотекам.
Чуть более подробно это расписано в отдельном посте в нашем англоязычном блоге.
В дополнение к этому, если вы разрабатываете проект на одной машине, а собираете/запускаете на другой, в CLion 2016.1 появилась возможность настроить автоматическую синхронизацию файлов по FTP, FTPS или SFTP.
Отладчик
Одна из самых долгожданных возможностей — отладка процесса, запущенного на локальной машине, из IDE. Конечно, многие спросят, а как же удаленная отладка? Пока нет, но до нее мы тоже доберемся!
К процессу можно подконектиться, указав его имя или идентификатор (pid). После установки соединения и при наличии исходного кода, открытого в CLion, Вам будут доступны все возможности встроенного отладчика — точки останова, просмотры значений переменных, вычисления выражений и пр.
Новые языки
В CLion 2016.1 появилась встроенная поддержка Python, а также доступен для установки плагин для поддержки Swift. Если у вас смешанный проект на Python/C/C++ или вас интересует Swift IDE на Linux, то милости просим! В плагинах поддержаны:
- стандартные для наших IDE возможности редактора (подсветка, автодополнение, форматирование)
- навигация по коду и поиск
- анализатор кода (для Python)
- рефакторинги
- отладка
Подробнее про возможности плагинов см. в нашем блоге: Python, Swift. А для короткого ознакомления предлагаем два видео:
И многое другое
В этот релиз также вошли следующие изменения:
- Новая команда для сброса CMake Cache. Позволяет почистить CMake Cache и при этом не сбрасывать кеши и индексы самой IDE.
- Поддержка multiple working trees для Git.
- Автоматическое создание Google Test конфигураций при загрузке проекта при наличии в проекте CMake таргета, слинкованного с gtest библиотекой.
- Кастомный билд JRE на Linux с исправлениями от команды JetBrains.
И, наконец, небольшое видео, демонстрирующее новые возможности CLion 2016.1:
Об этих и других возможностях новой версии можно почитать на сайте продукта. Следите также за статьями в нашем англоязычном блоге. Как обычно, есть 30-дневная бесплатная пробная версия, а в разделе цен можно узнать о стоимости. Мы будем рады ответить на любые ваши вопросы в комментариях.
Ваша команда JetBrains CLion
The Drive to Develop
Комментарии (92)
Randl
18.03.2016 20:10+2Баг с буфером обмена так и не пофиксили?
anastasiak2512
18.03.2016 21:22Мы пытаемся. Проблема в том, что нет надежного способа воспроизведения, что сильно усложняет задачу.
Randl
19.03.2016 05:08Видимо только мне не везет. Стабильно проявляется раз в примерно полчаса.
Может с обновлением лучше будетanastasiak2512
19.03.2016 05:52Если Вы сможете помочь со стабильным воспроизведением, будем вам очень благодарны. Отпишитесь в комментариях в тикете.
Randl
19.03.2016 12:40Так в том то и дело, что ничего не делаю. Никакой определенной последовательности действий, по крайней мере очевидной. Так что либо само по себе, либо что-то что я делаю постоянно и даже не обращаю на это внимания. Если ваши тестеры/разработчики
Обновлюсь — кину логи и всю что смогу, авось поможет.anastasiak2512
19.03.2016 20:30+1Вроде вчера удалось получить таки стабильный сценарий, который смогли повторить у нас. Так что теперь ждите фикс.
slonopotamus
18.03.2016 20:15+4С Unreal Engine 4 по-прежнему не дружит?
AlmazDelDiablo
18.03.2016 20:44А в чём именно они не дружат? Задаю вопрос, как человек, планирующий в течение года познакомиться с UE4 и никогда не использовавший CLion.
anastasiak2512
18.03.2016 21:25Что именно имеется в виду под "не дружит"? Мы обсуждали вот этом треде, какие есть возможности. Ничего специально в этом направлении не реализовывали.
VitaminPSG
18.03.2016 20:23Было бы не плохо прикрутить его к AndroidStudio. Очень не хватает отладки NDK.
anastasiak2512
18.03.2016 21:26+4Кого? AndroidStudio имеет поддержку C++, как раз на основе CLion сделанную.
BiTHacK
18.03.2016 21:38+2Есть какие-нибудь оценки по срокам, когда появится поддержка других систем сборки?
anastasiak2512
18.03.2016 21:56Тут история такая — мы думаем в сторону Makefiles. Но пока видим много проблем CMake модели. Если сейчас взяться за Makefile-ы, есть опасение, что эти же проблемы прорастут и в Makefiles. Поэтому мы хотим закончить важные вещи в CMake поддержке. Да и вообще негоже хвататься за вторую систему, не решив важных проблем в первой.
Думали, что в 2016.1 все критичные вещи в CMake закончим. Но, по ряду причин, не вышло.
iroln
19.03.2016 01:15А вот с этим есть какие-то подвижки?
https://youtrack.jetbrains.com/issue/CPP-1028
https://intellij-support.jetbrains.com/hc/en-us/community/posts/206608365-CLion-and-MITKanastasiak2512
19.03.2016 05:55Вот это как раз одна из таких критических вещей в CMake, с которой пока не получилось разобраться. В планах есть, но обещать пока ничего не могу.
iamwizard
18.03.2016 21:39+2У вас очень странная политика разделения на продукты. т.е. ReSharper AppCode — понятно, ибо биндинг к платфоме. С узконаправленными продуктами — тоже, нужна JS IDE — вот тебе WebStorm. А вот с мультиязыком и поддержкой фич в разных IDE — проблемы.
Например, есть проект на… Perl с С++ модулями и фронтендом на Angular. Задача — выбрать подходящую IDE из вашего набора:
1) perl — открытый плагин и встанет везде.
2) C++ есть только в CLion или он есть в IDEA Ultimate? (так-же как там есть… PHP, например)
3) html/css/less есть IDEA Ultimate, в storm, есть-ли он в CLion?
4) js есть в IDEA Ultimate, в storm (вероятно?) и скорее всего нет в CLion.
Самое интересное, что переход с подписки IDEA на "All Products" — не избавит меня от этих проблем — прийдется для одного проекта использовать несколько IDE.anastasiak2512
18.03.2016 21:53+1Давайnt по порядку:
2) планируется, просто задача не совсем первоочередная пока, поэтому отложена на несколько неопределенный срок. Надо бы хорошо понять, какие use case у такого.
3) есть
4) есть
Соб-но, веб фичи + С/С++ и Python/C/C++ нам кажутся наиболее частными случаями смешанного кода для C/C++. Поэтому они поддержаны. Остальные в порядке приоритетов.
Angular-а в CLion нет, но как-то никто и не просил пока особо.iamwizard
18.03.2016 22:38+5Спасибо за ответ.
Но, кажется я неправильно сформулировал основную проблемы:
-"Не понятно что есть в какждой конкретной IDE"
-"Не понятно быстро выбрать нужный тебе набор"
Т.е. вы говорите "планируется, просто задача не совсем первоочередная" — я правильно понимаю, что есть какие-то технические ограничения? Всмысле, я переехал на ваши продуты с Eclipse и его устройство кажется логичным — Базовая платформа + Плагины для языков. Ваши продукты выглядят так, что кажется что они устроенны аналогично, и вопрос включать тот или иной плагин в IDE — для вас "организационный" а не технический. Ну и то, что All Products Pack стоит дешевле чем каждая IDE в отдельности — подтверждает эту догадку.
Так вот, про use case: я могу привести несколько:
- PHP + C++ PHP framework phalcon, написанный на C++ как экстеншен для PHP
- Java + C++ — JNI
- Perl + C/C++ XS модули
- Flash ( AIR ) на iOS с С кодом. Flash в одной IDE, ObjC в другой, С в третьей.
И в тех случаях которые я видел — потребность возникает с первого языка. Т.е. человеку нужно только PHP, он покупает себе, допустим PHPStorm, а потом оказывается что ему нужны еще С++
Это очень странно. В смысле, если-бы у вас была базовая платформа (Вроде IDEA Community) и к ней можно было-бы докупать модули для языков-технологий (ну или бандл "все сразу в одной IDE") — это было-бы удобно, по крайней мере для тех разработчиков которых я знаю. А сейчас когда советуешь вашу IDE кому-то нельзя даже сказать "ну купи подписку на все" или "IDEA Ultimate тебе подойдет" потому что наверняка он наткнется на то, что ему прийдется открывать один проект в нескольких IDE.anastasiak2512
18.03.2016 23:48+1Тут скорее архитектурный вопрос — переносить в плагин только C++ как языковую поддержку или с проектной моделью? В обоих случаях есть свои плюсы и минусы. И в любом случае, это потребует ресурсов, так как исторически CLion "начался" в AppCode, который не поставляется как плагин к IntelliJ IDEA.
Про кейс с PHP согласна — он относительно частый, мы уже про такой несколько раз слыхали.
iOS разработка — это AppCode, там С/С++ как раз из CLion (у них в этом месте общая кодовая база просто исторически)
JNI — вроде есть Android Studio (с C++ поддержкой на базе CLion)
В общем, наверное, основания для плагина и правда есть, просто пока у нас совсем нет ресурсов на эту задачу (и она не кажется первоочередной).iamwizard
19.03.2016 00:14iOS разработка — это AppCode, там С/С++ как раз из CLion (у них в этом месте общая кодовая база просто исторически)
JNI — вроде есть Android Studio (с C++ поддержкой на базе CLion)
Дело в том, что есть кросплатформенные проекты.
Например уже приведенный пример — Flash + iOS/Android биндинги + С код. Нельзя получить Flash в Android Studio ибо он, насколько я знаю — он есть только в IDEA Ultimate, не говоря о том, что-бы получить все в одном месте.
Кстати интересно — сейчас посмотрел в IDEA Ultimate можно создать Android проект. В Android Studio можно создать Android проект (очевидно). Но там, еще по вашим словам, есть поддержка C++. В этом свете очень странно выглядит то, что в IDEA возможности поддержать С++.
Тут скорее архитектурный вопрос — переносить в плагин только C++ как языковую поддержку или с проектной моделью?
Вот тут я сольюсь ибо пользовался только IDEA Ultimate и не видел там большой разницы между Python/PHP/JS/Go/Perl/AS проектом.
Однако, можете прояснить, если вас не затрудит, чего НЕТ в IDEA Ultimate кроме проддержки С/С++ из CLion, ObjC, C# (очевидно).?
Ибо, например, там есть утилиты для работы с базой, но они такие-же как в DataGrip или нет?anastasiak2512
19.03.2016 00:39В IntelliJ IDEA соб-но нет всех языков — C/C++, Objective-C/Objective-C++, Swift. И нет проектной модели — CMake/Xcode. Что CLion, что AppCode довольно сильно повязаны на проектную модель, так как информация из нее используется для корректного парсинга и резолва. Поэтому перенести без проектной модели = сделать поддержку другой проектной модели, а мы пока не готовы к такому (ни по ресурсам, ни по ряду технических причин).
Про разнообразные проекты, для которых таки может понадобиться запустить CLion и еще какую-то нашу IDE, в целом я и не спорю. Да, есть такие случаи. Но опять же — это вопрос приоритетов.
Там, на самом деле, есть другая проблема. Запуск одновременно двух IDE наших на одном проекте приводит к тому, что они начинают показывать нотификацию и предлагать перезагрузить проект (отказаться можно, но это все равно действие какое-то). Что не удобно. Надеюсь, это мы скоро пофиксим.iamwizard
19.03.2016 01:04Спасибо.
Правильно-ли я понял, что остально — ( Python/PHP/JS/SQL ) в IDEA аналогично спецализированным IDE *Storm, DataGrip и т.д.?
Поэтому перенести без проектной модели = сделать поддержку другой проектной модели, а мы пока не готовы к такому (ни по ресурсам, ни по ряду технических причин).
А где у вас можно почитать про эту "проектную модель"?
Там, на самом деле, есть другая проблема. Запуск одновременно двух IDE наших на одном проекте приводит к тому, что они начинают показывать нотификацию и предлагать перезагрузить проект (отказаться можно, но это все равно действие какое-то). Что не удобно. Надеюсь, это мы скоро пофиксим.
А вот с этим я не сталкивался ни разу — обычно на разных языках все-таки написаны разные части проекта.anastasiak2512
19.03.2016 06:02Правильно-ли я понял, что остально — ( Python/PHP/JS/SQL ) в IDEA аналогично спецализированным IDE *Storm, DataGrip и т.д.?
В общем и целом да.
А где у вас можно почитать про эту "проектную модель"?
Открытого API у CLion на проектную модель нет, так что пока нигде.
обычно на разных языках все-таки написаны разные части проекта.
Даже при независимых частях, там достаточно иметь один общий проект с общей папкой настроек IDE, чтобы получить такие "конфликты". Вам видимо повезло.
klirichek
18.03.2016 22:19По-видимому опечатка или неточность:
"Одна из самых долгожданных возможностей — отладка процесса, запущенного на локальной машине из IDE".
Это же изначально было! А долгожданная возможность — отладка процесса, запущенного ВНЕ IDE! Иными словами — Attach to Process.
Но и тут ложка дёгтя: если вдруг не получилось (не хватило прав), то с консоли я могу повторить попытку через sudo, а у вас — увы, без вариантов.
Про кодогенерацию — тоже не выглядит особо круто.
(разные VAssist умеют подобное).
Причина — всё рассчитано по дефолту на паттерн — класс объявлен в файле класс.h(pp), определён в файле класс.cpp
Но! В реальной жизни всё может быть далеко не так! (может и неудобно, но наследие… Равно как и файлы размером >512000 байт. Последние нахрапом пользователей принУдили победить… А как с именами? Тоже нужно брут форс в багтреккер, или можно "на берегу" договориться?)
Ведь вроде очень просто же — видим объявление класса; смотрим, где оно — и рисуем меню. Если оно прямо в cpp — то это очевидно класс для внутреннего пользования, можно или вообще ничего не делать, или предложить какое-то дефолтное меню.
Если в хедере класс.h — то либо как сейчас, либо усложняем дальше.
Если "в каком-то хедере" (никакой корелляции с именем класса) — то тут уже "умный" выбор — добавить определение прямо в хедер (очевидно), добавить определение в <выпадающее меню .cpp-файлов проекта> (капельку сложнее), либо — по аналогии с пометкой папок — добавить пометки (=тэги, =связи) к хедерам — "классы, объявленные здесь, определяются в source1.cpp, source2.cpp… sourceN.cpp" — и именно эти файлы как варианты предлагать в меню выбора местоположения определений членов очередного объявленного в хедере класса.
Дальнейшая умность — эти самые возможные исходники определять самостоятельно (включив в список файлы, где уже живут определения объявленных в данном хедере классов). И выделять приоритетным (в верху списка вариантов) исходник, где определено подавляющее большинство членов того класса, где мы пытаемся объявить новый член.anastasiak2512
19.03.2016 01:03Это же изначально было! А долгожданная возможность — отладка процесса, запущенного ВНЕ IDE!
Запятая пропущена. Спасибо. Конечно, имелось в виду, что в IDE можно теперь отлаживать процесс, запущенный отдельно от IDE на локальной машине. Пишите баги в трекер — функционал новый, уверена, что мы его будем совершенствовать.
А как с именами? Тоже нужно брут форс в багтреккер, или можно "на берегу" договориться?
Не очень поняла, о чем речь.
Про кодогенерацию — вообще много интересных идей Вами описано. Тут главное найти баланс — между сложностью интерфейса, логичностью действий по умолчанию и желанию покрыть как можно больше вариантов использования.
Мы сейчас собрали достаточно фидбека и у нас (как нам кажется) есть хорошее понимание того, в каких случаях текущая логика может не подходить, и что с этим можно сделать. Часть изменений по usability кодогенерации попала в этот релиз, остальные ожидаются в ближайшем будущем (в том числе перекликающиеся с предложенными идеями).
vagran
18.03.2016 23:33+9Пытался когда-то попользоваться этой IDE, но её жёсткая привязанность к CMake сразу делает её бесполезной для множества проектов. В мире C/C++ среда сборки бывает очень разношёрстной, привязываться к какой-то одной — фатальный недостаток. Поддержка мейкфайлов тут тоже не очень поможет. Мне не в лом компилировать из командной строки (в некоторых проектах среда компиляции вообще бывает настроена на специальных сборочных серверах, и у разработчиков нет возможности компилировать и запускать бинарники локально, чувствуется влияние Java и т.п. технологий, но C/C++ — это совершенно из другой оперы). Хочется иметь удобную IDE, с качественной индексацией и прочими прелестями для удобной работы с кодом, совершенно не обязательна поддержка сборки в ней. После опыта использования IDEA с джавой были большие ожидания от clion, но ждало горькие разочарование. В ней действительно нельзя настроить вручную пути к заголовкам и символы препроцессора или я плохо искал? (до сих пор не могу в это поверить).
scrutari
19.03.2016 00:52+1Категорически поддерживаю этот комментарий: не хватает именно IDE. Помимо сказанного добавлю, что есть еще проекты с кросс-компиляцией, а также проекты на C++, собираемые maven. Да, подходов к сборке и управлению проектов множество, а IDE для C++ по-прежнему нет. В этом смысле молодцы создатели Qt Creator — там можно просто открыть папку с проектом и работать с исходным кодом, не привязываясь к конкретной системе сборки.
anastasiak2512
19.03.2016 01:09Понимаю все аргументы, но тут расчет был прост — надо откуда-то было брать кучу информации для парсера и резолва, чтобы IDE делала это максимально корректно. Но откуда? Варианты были либо писать свой формат проекта, либо брать существующий. Взяли в итоге существующий. При чем CMake не только один из самых популярных форматов для кросс-платформенных проектов, это же еще и агрегатор множества известных генераторов (он умеет и Makefile, и VS, итд).
Теперь про будущее. Конечно, мы тоже хотим, чтобы CLion позволял просто открыть папку с исходным кодом. И чтобы можно было просто вручную прописать пути к заголовкам, и пр. Это такой универсальный API над тем, что у нас сейчас для CMake сделано. И вообще он в мыслях/планах есть. Просто надо сначала текущие критичные проблемы с одной билд-системой порешать, прежде чем за такую унификацию браться. Нам так, по-крайней мере, кажется.
oYASo
19.03.2016 03:04И правильно сделали. Несмотря на обилие систем сборок для плюсовых проектов, в реальности право на жизнь имеют, имхо, только cmake, waf и qbs. Начинать писать сейчас проект на Makefile или Visual Studio Project, мягко говоря, очень странно.
С другой стороны, перетащить любой проект (Makefile, например) на тот же cmake — проблема скорее минут, нежели часов. Даже портирование таких монстров, как GDAL и Xerces-C++, заняло в свое время у меня пару часов.
Так что лично мне непонятно это нытье насчет поддержки множества систем сборок. Ну т.е. в этом нет ничего плохого, но есть куда более важные вещи, которые хочется видеть в современной IDE (типа поддержки Valgrind, которую от вас уже джва года ждут).anastasiak2512
19.03.2016 05:50+1Спасибо.
Про Valgrind — это, действительно, запрос еще со времен private preview, и мы даже думали про него в 2016.1, но не сложилось. Надеемся, что уже скоро сможем и его добавить.
Randl
20.03.2016 10:14+2Вряд ли крупный опенсорсный проект согласиться сменить систему сборки только из-за того вы пользуетесь IDE которая поддерживает только CMake.
Имеют или не имеют права на жизнь вопрос другой, но используются повсеместно и поддерживаться IDE должны имхо.
С другой стороны, для меня очень есть фичи и поважнее системы сборки, типа того же Valgrind и gprof. Развиваться есть куда, ребята работают над проектом, так что терпеливо ждем -_-
xvilka
21.03.2016 14:03Если makefile используется на всю мощь и рекурсивно, то перенос на cmake будет очень долгим и болезненным.
scrutari
19.03.2016 13:59-1Можно же просто анализировать код, а хедера брать либо из системных путей, либо оттуда, откуда написал пользователь.
Поддерживать разные системы сборки — это хорошо. Но главнее, мне кажется, удобство работы с кодом, что всегда отличали IDE от JetBrains.
Меня многие любители описывать сборку скриптами, а не моделями осудят, конечно, но cmake весьма спорный выбор особенно для тех, кто когда-то делал поддержку maven.oYASo
19.03.2016 19:40+2Ээээ… вы точно в курсе, что такое система сборки в мире C++? И зачем она вообще нужна, если можно просто брать из "системных путей, либо оттуда, откуда написал пользователь"?
Какие в мире C++ есть преимущества у maven по сравнению с cmake?scrutari
19.03.2016 23:06Да, я в курсе. Я говорил про анализ кода и навигацию по нему, когда сказал, что достаточно иметь сам код и используемые им хедера. Компилятору этого достаточно и без cmake-а :)
Какие в мире C++ есть преимущества у maven по сравнению с cmake?
Управление зависимостями, например, и отсутствие (почти) возможности писать скрипты (тем самым разрушая поддерживаемость больших проектов).oYASo
20.03.2016 01:22Да, я в курсе. Я говорил про анализ кода и навигацию по нему, когда сказал, что достаточно иметь сам код и используемые им хедера. Компилятору этого достаточно и без cmake-а :)
Это если проект небольшой, и все сорцы лежат под ногами. В реальности парсинг C++ кода — тот еще геморрой, и не то, чтобы идеальных инструментов, а даже очень хороших до сих пор еще нет. С этой задачей сейчас пытается справляться clang вкупе с IDE, которые его прикручивают, но результат все равно так себе. Например, на больших проектах clang code model в Qt Creator работает непозволительно медленно, а в более ранних версиях — просто отваливалась. Стандартная же кодовая модель ломается уже на auto.
И вот для того, чтобы clang работал корректно, ему нужно скормить весь код, собрать AST дерево и т.д. И вот тут уже нужные системы сборки, которые ему все это дадут.
Управление зависимостями, например, и отсутствие (почти) возможности писать скрипты (тем самым разрушая поддерживаемость больших проектов).
У любой системы сборки первостепенная задача — разрешить зависимости. В cmake это делается одной строчкой:
target_link_libraries(myproj lib1 lib2 lib3)
Все, теперь в myproj будут добавлены все необходимые хедеры, директивы препроцессора, ссылки на либы и прочее. Не знаю, что тут можно принципиально улучшить.
Что касается скриптов, то в этом весь cmake. Нормальная практика иметь файлы сборки cmake, внутри которого вызывается скрипт, написанный на cmake. Все эти find_package — те же самые скрипты по поиску сторонних либ.
cmake поддерживает тулчейны, package (rpm, deb, установщик на винду и прочее), позволяет прогать на своем макроязыке (который, если уж быть честным, так себе), умеет генерировать файлы проектов для всех популярных IDE (начиная от VS и заканчивая блокнотами типа Sublime Text), имеет поддержку ninja и дофига всего еще.
На сегодня просто нет альтернатив по функционалу.scrutari
20.03.2016 10:57Все, теперь в myproj будут добавлены все необходимые хедеры, директивы препроцессора, ссылки на либы и прочее
Это если все это установлено на билд хосте. А если нет? Иногда нужно линковать с чем-то, что не хочется или нельзя ставить в систему.
Плюс, не забывайте о кросс-компиляции. Да, в cmake можно для этого сделать подпрыгивание, и оно заработает, но в том же CLion эта фича cmake-а не поддерживается.
Cmake умеет много всего, жаль что они пошли по пути создания "языка": гугл теперь полон велосипедов, созданных в попытке решить конкретные задачи разработки — то есть нет единого подхода в создании проектов на cmake, что рождает тучу сами-понимаете-каких скриптов и функций даже там, где встроенными средствами легко обойтись. Идея cmake-а очень правильная, но выбранная реализация губит почти все хорошие начинания.
Кстати, cmake создает лишь иллюзию кроссплатформенности сборки — он генерит для Windows файлы проекта, но не дает возможности выполнить сборку. С maven это можно решить, сделав сборку не зависимой от платформы, когда одной и той же командой можно собрать проект и на Windows и на Linux.
nikolayz
20.03.2016 13:24На самом деле, cmake все-таки позволяет собрать проект двумя командами на любой платформе. Сначала вы генерируете проект обычным способом, а затем используете команду cmake --build. для сборки. Для каждого генератора будет выполнен соответствующий ему сборщик, например для Visual Studio это будет MSBuild, а на Unix это будет, например, Make.
iroln
20.03.2016 20:42Это если все это установлено на билд хосте. А если нет? Иногда нужно линковать с чем-то, что не хочется или нельзя ставить в систему.
ExternalProject разве не решает эту проблему? Если какие-то зависимости отсутствуют в системе, их можно подключить в виде ExternalProject-зависимостей, которые будут загружены при сборке либо в виде уже готовых библиотек, либо в виде исходного кода, собираемого перед сборкой основных целей.
Конечно, это может сильно усложнить, раздуть и запутать конфигурацию сборки проекта, но бывает и довольно удобно сделать такой «Superbuild» для проекта с развесистым списком зависимостей.
Кстати, CLion, вроде, такие штуки не поддерживает. :(anastasiak2512
21.03.2016 06:19+1Руки не дошли пока протестить хорошо, но вроде пользователи пишут, что работает. В ближайшее время, надеюсь, доберемся проверить/дофиксить.
Daffodil
20.03.2016 01:12+2К сожалению CMake очень не гибкое средство. Как настроить билд компиляторами не поддерживаемыми из коробки я так и не смог понять. Судя по всему единственный способ — делать форк CMake'a. В результате пишу одновременно Makefile и CMakeLists.txt: первый для билда, второй для CLion :((
oYASo
20.03.2016 01:25+1Daffodil
20.03.2016 03:20Насколько я понимаю оно позволяет настроить пути к компилятору, но я не вижу способов настроить способ передачи опций компилятору. Т.е. оно всё равно будет считать что компилятор GCC-совместимый. Хотя мой тулчейн (Synopsys VCS) и содержит внутри себя GCC, но собираются проекты всё равно слегка иначе.
Я пытался вытащить через переменные CMake списки исходников, пути к либам и пр. а затем собирать проект с помощью add_custom_command и add_custom_target. Но в итоге решил что проще будет писать Makefile и CMakeLists.txt
Надеюсь что в Clion в итоге сделают поддержку ручной настройки проека (как в Eclipse CDT) и я смогу спокойно обходится одними Makefiles.nikolayz
20.03.2016 13:45+1Есть возможность настроить флаги в toolchain-файле, например вот так:
set(CMAKE_C_COMPILE_OBJECT "<CMAKE_C_COMPILER> <DEFINES> <INCLUDES> <FLAGS> -o <OBJECT> -c <SOURCE>") set(CMAKE_C_LINK_EXECUTABLE "<CMAKE_C_COMPILER> <FLAGS> <CMAKE_C_LINK_FLAGS> <LINK_FLAGS> <OBJECTS> -o <TARGET> <LINK_LIBRARIES>")
Вообще, в CMake все стандартные тулчейны настраиваются обычными cmake-скриптами, которые лежат в "<путь-установки>/share/cmake/Modules" (большинство из них — в директориях Compiler и Platform) и там можно почерпнуть много информации. Но скрипты там не очень очевидные и да, я согласен, что это очень плохо документировано.Daffodil
20.03.2016 20:35Спасибо! Начал копать.
Пока оно у меня валится на compiler check, точнее на линковке. Потому что VCS предполагает что функция main будет называться sc_main. Следовательно падает всё на undefined reference to `sc_main'
Как настроить ему исходники для проверки компилятора я пока не понял.
Daffodil
20.03.2016 20:52Всё, Hello world мне удалось собрать.
Выключил проверку компиляторов с помощью
set(CMAKE_CXX_COMPILER_FORCED TRUE)
set(CMAKE_C_COMPILER_FORCED TRUE)
scrutari
20.03.2016 11:04+2Да, toolchains, только лучше вот эти: toolchains :)
С cmake в том-то и проблема, что куча странных вариантов сделать одно и то же, придуманных из-за безысходности. За этими вариантами в поисковой выдаче порой не видно хороших встроенных инструментов.
cutwater
19.03.2016 00:48Есть ли планы относительно поддержки удаленного компилятора и отладчика? Типичный use-case, когда разработка проекта ведется на MacOS X, а сборка и тестирование на Linux VM \ Remote server. Ставить десктопный Linux ради разработки и сборки на одном окружении не всегда представляется удобным и\или возможным.
anastasiak2512
19.03.2016 01:10Есть. Соб-но, attach to local process первый шаг в направлении remote debug. Ну и компиляция там тоже где-то. Запрос к трекере — CPP-744
robert_ayrapetyan
19.03.2016 06:58Скажите, а владельцу Perpetual License на предыдущую версию, пару недель назад ее продлившему, снова нужно платить за новую версию? Спасибо.
anastasiak2512
19.03.2016 10:29+1Если у Вас есть действующая подписка (а раз Вы ее недавно продлили, то, вероятно, есть) на CLion, то ничего дополнительно платить не надо.
robert_ayrapetyan
19.03.2016 19:10Спасибо! К сожалению, пришлось сразу откатиться на старую версию, в связи с полной потерей совместимости. Создал баг https://youtrack.jetbrains.com/issue/CPP-6164, надеюсь на скорый фикс.
anastasiak2512
19.03.2016 20:32+1Workaround, я так понимаю, помог?
Спасибо за репорт, посмотрим в самое ближайшее время.
pavelodintsov
19.03.2016 21:16Хотеть поддержку сборки удаленных проектов по ssh! :)
anastasiak2512
20.03.2016 07:04А в таком случае проект полностью лежит удаленно? То есть как предполагается с ним работать — полностью по сети или копировать сорсы на локальную машину?
pavelodintsov
20.03.2016 13:46Доступ к файлам, разумеется, есть, силами sshfs: http://www.stableit.ru/2016/03/ssh-mac-os-x-el-capitan.html А вот сборку на удаленной машине не запустить никак в текущей версии :(
Я себе это вижу как настраиваемый путь к команде сборки. Чтобы, например, вместо cmake… и make делать соотвественно: ssh remote_server_ip "cmake .." и ssh remote_server_ip "make".
На С и С++ сейчас редко пишут под десктоп, поэтому у Вас в тикете с описанием сабжа очень высокая активность. На своей машине при всем желании я не могу иметь софт, который проворачивает 40 гигабит данных либо является встраиваемым устройством :)anastasiak2512
21.03.2016 06:21+1Спасибо за описание кейса. В целом понятно, что именно надо делать. Будем думать, когда за это взяться.
scrutari
20.03.2016 11:06Если это работает: хотеть поддержку тулчейнов и еще хотеть, чтобы все-таки я был автором CMakeLists.txt, а не IDE, которая все время пытается переделать этот файл.
anastasiak2512
20.03.2016 11:26+1IDE туда предлагает добавить файлы при создании (но это опционально, и можно галочку в диалоге отключить). Вроде больше никак не трогает CMakeLists.txt. Что имеется в виду?
scrutari
20.03.2016 18:42Если я добавляю файлы в проект не явно, а как-то еще, то CLion думает все время, что я их забыл добавить и, соответственно, добавляет их с завидным усердием.
Мне кажется, что все дело в том, что существует множество способов использовать cmake, и не все из них очевидны, и тем более не все поддерживаются CLion.
Помимо добавления файлов еще очень непонятно, как добиться расположения всех файлов cmake-а в папке "./build", а не где-то там в странной папке в недрах CLion.
Мне бы хотелось по рабоче-крестьянски просто навигацию по коду и автокомплит в редакторе. Цены бы не было. А сборку я уж сам, из консоли.
С Java, кстати, та же проблема была — там все время Idea генерила какие-то артефакты, хотя они не были нужны (там я тоже сборку из консоли всегда запускал).Daffodil
20.03.2016 21:00Папку build можно настроить с помощью
set(CMAKE_RUNTIME_OUTPUT_DIRECTORY "${CMAKE_CURRENT_SOURCE_DIR}/build")iroln
20.03.2016 21:32CMAKE_RUNTIME_OUTPUT_DIRECTORY — это папка в которую складываются выходные файлы сборки (исполняемые файлы и библиотеки). Я думаю, имелось в виду настройка папки сборки — это папка CMAKE_BINARY_DIR.
anastasiak2512
21.03.2016 06:27Про .build — сейчас нельзя сменить директорию, где запускается команда cmake. Можно только сменить директорию, куда копируются артифакты сборки. И хотя так было сделано by design, мы задумываемся, чтобы все же это изменить.
Мне бы хотелось по рабоче-крестьянски просто навигацию по коду и автокомплит в редакторе. Цены бы не было. А сборку я уж сам, из консоли.
Так дело то не в сборке. Запуск cmake и понимание cmake файлов нужны ровно для того, чтобы навигация, автоополнение и др. "умные" фишки редактора работали корректно. Нужно понимать, какие и где заголовочные файлы, какие переменные в CMake определены, какой стандарт языка используется, и пр.
chersanya
20.03.2016 11:33Во многих случаях clion показывает ошибку в коде, где её на самом деле нет — я так понимаю, из-за какого-то упрощённого парсера, который не воспринимает некоторые возможности языка. Например — даже из туториала по boost (http://www.boost.org/doc/libs/1_60_0/more/getting_started/unix-variants.html, пункт 4) программа с использованием бустовской лямбды. Ещё из того, что у себя заметил — подсвечивает ошибками определение и использование суффиксов (которые user-defined literal из C++11), или например применение | к значениям enum'а иногда.
Кажется, что это не проблема нескольких частных случаев, а достаточно общая.anastasiak2512
20.03.2016 11:37User defined литералы пока не поддерживаются.
Остальные ошибки можно (и даже нужно) репортить к нам в трекер. Мы будем их исправлять.chersanya
20.03.2016 11:40+2А что используется для подсветки ошибок? Из-за того, что появляются такие баги, можно предположить что какое-то своё решение — собственно, почему не clang например?
anastasiak2512
21.03.2016 06:34Парсер — свой. Причин — много (я их как-то описывала вот здесь в разделе C++ parser).
Если отбросить все исторические и архитектурные, то в случае IDE парсер должен уметь нечто, что парсеру в компиляторе в общем не нужно — кеш индексов на весь проект. Это необходимо для того, чтобы те же рефакторинги могли работать на всем проекте, а не только на том файле, где вызваны, с приемлемой производительностью.
То есть можно взять libclang, получить отличный код без false-positives и красного кода в редакторе, но потом с этим кодом будет ничего не сделать толком. Такой вариант нас не устраивает. Libclang, конечно, движется в сторону IDE, но пока простого варианта ее использования мы не видим.
tangro
21.03.2016 12:22Меня лично очень радует развитие поддержки Python. Какой ты проект на С++ не пиши с какого-то момента неприменно вылазит необходимость "вот тут и тут ма-а-а-ахонький скриптик бы на чём-то таком типа руби или питона". Отсутствие удобных средств что-то такое сделать меня очень напрягало в Visual Studio до появления Python Tools в её последних версиях. Радует, что CLion дошел до понимания данной проблемы значительно быстрее.
ik62
хочется dlang...
anastasiak2512
Кто-то вот делает плагин (3rd party).
ik62
там ну очень мало сделано и прогресс не виден. Приходится использовать pycharm (оплаченный!) для питона и отдельно monodevelop для D
anastasiak2512
Я к тому, что, наверное, можно присоединиться к разработке плагина. У нас пока планов нет.
Rathil
Жалко, очень хотелось.
GooRoo
хочется QML
anastasiak2512
Вот здесь уже просили. Но вряд ли это в ближайшие планы попадет.
GooRoo
Ну как минимум теперь ясно, что ожидать это не стоит. Спасибо.