company_banner

Релиз CLion 2016.1: новые инструменты и новые языки

    Привет, Хабр!

    У нас сегодня отличные новости — вышел очередной релиз нашей кросс-платорфменной среды для разработки на 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

    JetBrains

    162,90

    Делаем эффективные инструменты для разработчиков

    Поделиться публикацией
    Комментарии 99
      0
      хочется dlang...
        0
        Кто-то вот делает плагин (3rd party).
          0
          там ну очень мало сделано и прогресс не виден. Приходится использовать pycharm (оплаченный!) для питона и отдельно monodevelop для D
            +4
            Я к тому, что, наверное, можно присоединиться к разработке плагина. У нас пока планов нет.
              0
              Жалко, очень хотелось.
          0
          хочется QML
            0
            Вот здесь уже просили. Но вряд ли это в ближайшие планы попадет.
              +1
              Ну как минимум теперь ясно, что ожидать это не стоит. Спасибо.
          +2
          Баг с буфером обмена так и не пофиксили?
            0
            Мы пытаемся. Проблема в том, что нет надежного способа воспроизведения, что сильно усложняет задачу.
              0
              Видимо только мне не везет. Стабильно проявляется раз в примерно полчаса.
              Может с обновлением лучше будет
                0
                Если Вы сможете помочь со стабильным воспроизведением, будем вам очень благодарны. Отпишитесь в комментариях в тикете.
                  0
                  Так в том то и дело, что ничего не делаю. Никакой определенной последовательности действий, по крайней мере очевидной. Так что либо само по себе, либо что-то что я делаю постоянно и даже не обращаю на это внимания. Если ваши тестеры/разработчики

                  Обновлюсь — кину логи и всю что смогу, авось поможет.
                    +1
                    Вроде вчера удалось получить таки стабильный сценарий, который смогли повторить у нас. Так что теперь ждите фикс.
            +4
            С Unreal Engine 4 по-прежнему не дружит?
              0
              А в чём именно они не дружат? Задаю вопрос, как человек, планирующий в течение года познакомиться с UE4 и никогда не использовавший CLion.
                0
                Что именно имеется в виду под "не дружит"? Мы обсуждали вот этом треде, какие есть возможности. Ничего специально в этом направлении не реализовывали.
                  0
                  Да, мы обсуждали в том треде (а потом ещё и с fsmorygo в скайпе) и в результате пришли к тому, что CLion не работает с UE4 вообще никак. В чём-то это проблема UE4, в котором самодельная тулза для генерации CMakeLists.txt, в чём-то это проблема CLion'а.

                  Но до сих пор тривиальный кейс вида «скачать UE4, Setup.sh, GenerateProjectFiles.sh, clion CMakeLists.txt» даёт на выходе неюзабельное нечто, в котором даже кнопку Build нажать нельзя, я уж не говорю о навигации по исходникам.

                  Только что перепроверил на CLion 2016.1 + UE4 4.11, ничего не изменилось.
                    0
                    Да, коллеги напомнили мне, в чем там были проблемы. Похоже, что ситуацию спасет add_custom_target, который мы планируем поддержать в 2016.2
                0
                Было бы не плохо прикрутить его к AndroidStudio. Очень не хватает отладки NDK.
                  +4
                  Кого? AndroidStudio имеет поддержку C++, как раз на основе CLion сделанную.
                  +2
                  Есть какие-нибудь оценки по срокам, когда появится поддержка других систем сборки?
                    0
                    Тут история такая — мы думаем в сторону Makefiles. Но пока видим много проблем CMake модели. Если сейчас взяться за Makefile-ы, есть опасение, что эти же проблемы прорастут и в Makefiles. Поэтому мы хотим закончить важные вещи в CMake поддержке. Да и вообще негоже хвататься за вторую систему, не решив важных проблем в первой.

                    Думали, что в 2016.1 все критичные вещи в CMake закончим. Но, по ряду причин, не вышло.
                  +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.
                    +1
                    Давайnt по порядку:

                    2) планируется, просто задача не совсем первоочередная пока, поэтому отложена на несколько неопределенный срок. Надо бы хорошо понять, какие use case у такого.
                    3) есть
                    4) есть

                    Соб-но, веб фичи + С/С++ и Python/C/C++ нам кажутся наиболее частными случаями смешанного кода для C/C++. Поэтому они поддержаны. Остальные в порядке приоритетов.

                    Angular-а в CLion нет, но как-то никто и не просил пока особо.
                      +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.
                        +1
                        Тут скорее архитектурный вопрос — переносить в плагин только C++ как языковую поддержку или с проектной моделью? В обоих случаях есть свои плюсы и минусы. И в любом случае, это потребует ресурсов, так как исторически CLion "начался" в AppCode, который не поставляется как плагин к IntelliJ IDEA.

                        Про кейс с PHP согласна — он относительно частый, мы уже про такой несколько раз слыхали.
                        iOS разработка — это AppCode, там С/С++ как раз из CLion (у них в этом месте общая кодовая база просто исторически)
                        JNI — вроде есть Android Studio (с C++ поддержкой на базе CLion)

                        В общем, наверное, основания для плагина и правда есть, просто пока у нас совсем нет ресурсов на эту задачу (и она не кажется первоочередной).
                          0
                          iOS разработка — это 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 или нет?
                            0
                            В IntelliJ IDEA соб-но нет всех языков — C/C++, Objective-C/Objective-C++, Swift. И нет проектной модели — CMake/Xcode. Что CLion, что AppCode довольно сильно повязаны на проектную модель, так как информация из нее используется для корректного парсинга и резолва. Поэтому перенести без проектной модели = сделать поддержку другой проектной модели, а мы пока не готовы к такому (ни по ресурсам, ни по ряду технических причин).

                            Про разнообразные проекты, для которых таки может понадобиться запустить CLion и еще какую-то нашу IDE, в целом я и не спорю. Да, есть такие случаи. Но опять же — это вопрос приоритетов.

                            Там, на самом деле, есть другая проблема. Запуск одновременно двух IDE наших на одном проекте приводит к тому, что они начинают показывать нотификацию и предлагать перезагрузить проект (отказаться можно, но это все равно действие какое-то). Что не удобно. Надеюсь, это мы скоро пофиксим.
                              0
                              Спасибо.
                              Правильно-ли я понял, что остально — ( Python/PHP/JS/SQL ) в IDEA аналогично спецализированным IDE *Storm, DataGrip и т.д.?

                              Поэтому перенести без проектной модели = сделать поддержку другой проектной модели, а мы пока не готовы к такому (ни по ресурсам, ни по ряду технических причин).

                              А где у вас можно почитать про эту "проектную модель"?

                              Там, на самом деле, есть другая проблема. Запуск одновременно двух IDE наших на одном проекте приводит к тому, что они начинают показывать нотификацию и предлагать перезагрузить проект (отказаться можно, но это все равно действие какое-то). Что не удобно. Надеюсь, это мы скоро пофиксим.

                              А вот с этим я не сталкивался ни разу — обычно на разных языках все-таки написаны разные части проекта.
                                0
                                Правильно-ли я понял, что остально — ( Python/PHP/JS/SQL ) в IDEA аналогично спецализированным IDE *Storm, DataGrip и т.д.?

                                В общем и целом да.

                                А где у вас можно почитать про эту "проектную модель"?

                                Открытого API у CLion на проектную модель нет, так что пока нигде.

                                обычно на разных языках все-таки написаны разные части проекта.

                                Даже при независимых частях, там достаточно иметь один общий проект с общей папкой настроек IDE, чтобы получить такие "конфликты". Вам видимо повезло.
                    0
                    По-видимому опечатка или неточность:
                    "Одна из самых долгожданных возможностей — отладка процесса, запущенного на локальной машине из IDE".
                    Это же изначально было! А долгожданная возможность — отладка процесса, запущенного ВНЕ IDE! Иными словами — Attach to Process.
                    Но и тут ложка дёгтя: если вдруг не получилось (не хватило прав), то с консоли я могу повторить попытку через sudo, а у вас — увы, без вариантов.

                    Про кодогенерацию — тоже не выглядит особо круто.
                    (разные VAssist умеют подобное).
                    Причина — всё рассчитано по дефолту на паттерн — класс объявлен в файле класс.h(pp), определён в файле класс.cpp
                    Но! В реальной жизни всё может быть далеко не так! (может и неудобно, но наследие… Равно как и файлы размером >512000 байт. Последние нахрапом пользователей принУдили победить… А как с именами? Тоже нужно брут форс в багтреккер, или можно "на берегу" договориться?)

                    Ведь вроде очень просто же — видим объявление класса; смотрим, где оно — и рисуем меню. Если оно прямо в cpp — то это очевидно класс для внутреннего пользования, можно или вообще ничего не делать, или предложить какое-то дефолтное меню.
                    Если в хедере класс.h — то либо как сейчас, либо усложняем дальше.
                    Если "в каком-то хедере" (никакой корелляции с именем класса) — то тут уже "умный" выбор — добавить определение прямо в хедер (очевидно), добавить определение в <выпадающее меню .cpp-файлов проекта> (капельку сложнее), либо — по аналогии с пометкой папок — добавить пометки (=тэги, =связи) к хедерам — "классы, объявленные здесь, определяются в source1.cpp, source2.cpp… sourceN.cpp" — и именно эти файлы как варианты предлагать в меню выбора местоположения определений членов очередного объявленного в хедере класса.
                    Дальнейшая умность — эти самые возможные исходники определять самостоятельно (включив в список файлы, где уже живут определения объявленных в данном хедере классов). И выделять приоритетным (в верху списка вариантов) исходник, где определено подавляющее большинство членов того класса, где мы пытаемся объявить новый член.
                      0
                      Это же изначально было! А долгожданная возможность — отладка процесса, запущенного ВНЕ IDE!

                      Запятая пропущена. Спасибо. Конечно, имелось в виду, что в IDE можно теперь отлаживать процесс, запущенный отдельно от IDE на локальной машине. Пишите баги в трекер — функционал новый, уверена, что мы его будем совершенствовать.

                      А как с именами? Тоже нужно брут форс в багтреккер, или можно "на берегу" договориться?

                      Не очень поняла, о чем речь.

                      Про кодогенерацию — вообще много интересных идей Вами описано. Тут главное найти баланс — между сложностью интерфейса, логичностью действий по умолчанию и желанию покрыть как можно больше вариантов использования.
                      Мы сейчас собрали достаточно фидбека и у нас (как нам кажется) есть хорошее понимание того, в каких случаях текущая логика может не подходить, и что с этим можно сделать. Часть изменений по usability кодогенерации попала в этот релиз, остальные ожидаются в ближайшем будущем (в том числе перекликающиеся с предложенными идеями).
                      +9
                      Пытался когда-то попользоваться этой IDE, но её жёсткая привязанность к CMake сразу делает её бесполезной для множества проектов. В мире C/C++ среда сборки бывает очень разношёрстной, привязываться к какой-то одной — фатальный недостаток. Поддержка мейкфайлов тут тоже не очень поможет. Мне не в лом компилировать из командной строки (в некоторых проектах среда компиляции вообще бывает настроена на специальных сборочных серверах, и у разработчиков нет возможности компилировать и запускать бинарники локально, чувствуется влияние Java и т.п. технологий, но C/C++ — это совершенно из другой оперы). Хочется иметь удобную IDE, с качественной индексацией и прочими прелестями для удобной работы с кодом, совершенно не обязательна поддержка сборки в ней. После опыта использования IDEA с джавой были большие ожидания от clion, но ждало горькие разочарование. В ней действительно нельзя настроить вручную пути к заголовкам и символы препроцессора или я плохо искал? (до сих пор не могу в это поверить).
                      • НЛО прилетело и опубликовало эту надпись здесь
                          0
                          Понимаю все аргументы, но тут расчет был прост — надо откуда-то было брать кучу информации для парсера и резолва, чтобы IDE делала это максимально корректно. Но откуда? Варианты были либо писать свой формат проекта, либо брать существующий. Взяли в итоге существующий. При чем CMake не только один из самых популярных форматов для кросс-платформенных проектов, это же еще и агрегатор множества известных генераторов (он умеет и Makefile, и VS, итд).

                          Теперь про будущее. Конечно, мы тоже хотим, чтобы CLion позволял просто открыть папку с исходным кодом. И чтобы можно было просто вручную прописать пути к заголовкам, и пр. Это такой универсальный API над тем, что у нас сейчас для CMake сделано. И вообще он в мыслях/планах есть. Просто надо сначала текущие критичные проблемы с одной билд-системой порешать, прежде чем за такую унификацию браться. Нам так, по-крайней мере, кажется.
                            0
                            И правильно сделали. Несмотря на обилие систем сборок для плюсовых проектов, в реальности право на жизнь имеют, имхо, только cmake, waf и qbs. Начинать писать сейчас проект на Makefile или Visual Studio Project, мягко говоря, очень странно.

                            С другой стороны, перетащить любой проект (Makefile, например) на тот же cmake — проблема скорее минут, нежели часов. Даже портирование таких монстров, как GDAL и Xerces-C++, заняло в свое время у меня пару часов.

                            Так что лично мне непонятно это нытье насчет поддержки множества систем сборок. Ну т.е. в этом нет ничего плохого, но есть куда более важные вещи, которые хочется видеть в современной IDE (типа поддержки Valgrind, которую от вас уже джва года ждут).
                              +1
                              Спасибо.
                              Про Valgrind — это, действительно, запрос еще со времен private preview, и мы даже думали про него в 2016.1, но не сложилось. Надеемся, что уже скоро сможем и его добавить.
                                +2
                                Вряд ли крупный опенсорсный проект согласиться сменить систему сборки только из-за того вы пользуетесь IDE которая поддерживает только CMake.

                                Имеют или не имеют права на жизнь вопрос другой, но используются повсеместно и поддерживаться IDE должны имхо.

                                С другой стороны, для меня очень есть фичи и поважнее системы сборки, типа того же Valgrind и gprof. Развиваться есть куда, ребята работают над проектом, так что терпеливо ждем -_-
                                  0
                                  Если makefile используется на всю мощь и рекурсивно, то перенос на cmake будет очень долгим и болезненным.
                                • НЛО прилетело и опубликовало эту надпись здесь
                                    +2
                                    Ээээ… вы точно в курсе, что такое система сборки в мире C++? И зачем она вообще нужна, если можно просто брать из "системных путей, либо оттуда, откуда написал пользователь"?

                                    Какие в мире C++ есть преимущества у maven по сравнению с cmake?
                                    • НЛО прилетело и опубликовало эту надпись здесь
                                        0
                                        Да, я в курсе. Я говорил про анализ кода и навигацию по нему, когда сказал, что достаточно иметь сам код и используемые им хедера. Компилятору этого достаточно и без 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 и дофига всего еще.
                                        На сегодня просто нет альтернатив по функционалу.
                                        • НЛО прилетело и опубликовало эту надпись здесь
                                            0
                                            На самом деле, cmake все-таки позволяет собрать проект двумя командами на любой платформе. Сначала вы генерируете проект обычным способом, а затем используете команду cmake --build. для сборки. Для каждого генератора будет выполнен соответствующий ему сборщик, например для Visual Studio это будет MSBuild, а на Unix это будет, например, Make.
                                              0
                                              Это если все это установлено на билд хосте. А если нет? Иногда нужно линковать с чем-то, что не хочется или нельзя ставить в систему.
                                              ExternalProject разве не решает эту проблему? Если какие-то зависимости отсутствуют в системе, их можно подключить в виде ExternalProject-зависимостей, которые будут загружены при сборке либо в виде уже готовых библиотек, либо в виде исходного кода, собираемого перед сборкой основных целей.

                                              Конечно, это может сильно усложнить, раздуть и запутать конфигурацию сборки проекта, но бывает и довольно удобно сделать такой «Superbuild» для проекта с развесистым списком зависимостей.

                                              Кстати, CLion, вроде, такие штуки не поддерживает. :(
                                                +1
                                                Руки не дошли пока протестить хорошо, но вроде пользователи пишут, что работает. В ближайшее время, надеюсь, доберемся проверить/дофиксить.
                                      +2
                                      К сожалению CMake очень не гибкое средство. Как настроить билд компиляторами не поддерживаемыми из коробки я так и не смог понять. Судя по всему единственный способ — делать форк CMake'a. В результате пишу одновременно Makefile и CMakeLists.txt: первый для билда, второй для CLion :((
                                        +1
                                          0
                                          Насколько я понимаю оно позволяет настроить пути к компилятору, но я не вижу способов настроить способ передачи опций компилятору. Т.е. оно всё равно будет считать что компилятор GCC-совместимый. Хотя мой тулчейн (Synopsys VCS) и содержит внутри себя GCC, но собираются проекты всё равно слегка иначе.

                                          Я пытался вытащить через переменные CMake списки исходников, пути к либам и пр. а затем собирать проект с помощью add_custom_command и add_custom_target. Но в итоге решил что проще будет писать Makefile и CMakeLists.txt

                                          Надеюсь что в Clion в итоге сделают поддержку ручной настройки проека (как в Eclipse CDT) и я смогу спокойно обходится одними Makefiles.
                                            +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) и там можно почерпнуть много информации. Но скрипты там не очень очевидные и да, я согласен, что это очень плохо документировано.
                                              0
                                              Спасибо! Начал копать.
                                              Пока оно у меня валится на compiler check, точнее на линковке. Потому что VCS предполагает что функция main будет называться sc_main. Следовательно падает всё на undefined reference to `sc_main'

                                              Как настроить ему исходники для проверки компилятора я пока не понял.
                                                0
                                                Всё, Hello world мне удалось собрать.
                                                Выключил проверку компиляторов с помощью
                                                set(CMAKE_CXX_COMPILER_FORCED TRUE)
                                                set(CMAKE_C_COMPILER_FORCED TRUE)
                                            • НЛО прилетело и опубликовало эту надпись здесь
                                      0
                                      Есть ли планы относительно поддержки удаленного компилятора и отладчика? Типичный use-case, когда разработка проекта ведется на MacOS X, а сборка и тестирование на Linux VM \ Remote server. Ставить десктопный Linux ради разработки и сборки на одном окружении не всегда представляется удобным и\или возможным.
                                        0
                                        Есть. Соб-но, attach to local process первый шаг в направлении remote debug. Ну и компиляция там тоже где-то. Запрос к трекере — CPP-744
                                        0
                                        Скажите, а владельцу Perpetual License на предыдущую версию, пару недель назад ее продлившему, снова нужно платить за новую версию? Спасибо.
                                          +1
                                          Если у Вас есть действующая подписка (а раз Вы ее недавно продлили, то, вероятно, есть) на CLion, то ничего дополнительно платить не надо.
                                            0
                                            Спасибо! К сожалению, пришлось сразу откатиться на старую версию, в связи с полной потерей совместимости. Создал баг https://youtrack.jetbrains.com/issue/CPP-6164, надеюсь на скорый фикс.
                                              +1
                                              Workaround, я так понимаю, помог?
                                              Спасибо за репорт, посмотрим в самое ближайшее время.
                                        0
                                        Хотеть поддержку сборки удаленных проектов по ssh! :)
                                          0
                                          А в таком случае проект полностью лежит удаленно? То есть как предполагается с ним работать — полностью по сети или копировать сорсы на локальную машину?
                                            0
                                            Доступ к файлам, разумеется, есть, силами 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 гигабит данных либо является встраиваемым устройством :)
                                              +1
                                              Спасибо за описание кейса. В целом понятно, что именно надо делать. Будем думать, когда за это взяться.
                                                0
                                                Спасибо, ждем нетерпением! :)
                                        • НЛО прилетело и опубликовало эту надпись здесь
                                            +1
                                            IDE туда предлагает добавить файлы при создании (но это опционально, и можно галочку в диалоге отключить). Вроде больше никак не трогает CMakeLists.txt. Что имеется в виду?
                                            • НЛО прилетело и опубликовало эту надпись здесь
                                                0
                                                Папку build можно настроить с помощью
                                                set(CMAKE_RUNTIME_OUTPUT_DIRECTORY "${CMAKE_CURRENT_SOURCE_DIR}/build")
                                                  0
                                                  CMAKE_RUNTIME_OUTPUT_DIRECTORY — это папка в которую складываются выходные файлы сборки (исполняемые файлы и библиотеки). Я думаю, имелось в виду настройка папки сборки — это папка CMAKE_BINARY_DIR.
                                                  0
                                                  Про .build — сейчас нельзя сменить директорию, где запускается команда cmake. Можно только сменить директорию, куда копируются артифакты сборки. И хотя так было сделано by design, мы задумываемся, чтобы все же это изменить.

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

                                                  Так дело то не в сборке. Запуск cmake и понимание cmake файлов нужны ровно для того, чтобы навигация, автоополнение и др. "умные" фишки редактора работали корректно. Нужно понимать, какие и где заголовочные файлы, какие переменные в CMake определены, какой стандарт языка используется, и пр.
                                              0
                                              Во многих случаях clion показывает ошибку в коде, где её на самом деле нет — я так понимаю, из-за какого-то упрощённого парсера, который не воспринимает некоторые возможности языка. Например — даже из туториала по boost (http://www.boost.org/doc/libs/1_60_0/more/getting_started/unix-variants.html, пункт 4) программа с использованием бустовской лямбды. Ещё из того, что у себя заметил — подсвечивает ошибками определение и использование суффиксов (которые user-defined literal из C++11), или например применение | к значениям enum'а иногда.

                                              Кажется, что это не проблема нескольких частных случаев, а достаточно общая.
                                                0
                                                User defined литералы пока не поддерживаются.
                                                Остальные ошибки можно (и даже нужно) репортить к нам в трекер. Мы будем их исправлять.
                                                  +2
                                                  А что используется для подсветки ошибок? Из-за того, что появляются такие баги, можно предположить что какое-то своё решение — собственно, почему не clang например?
                                                    0
                                                    Парсер — свой. Причин — много (я их как-то описывала вот здесь в разделе C++ parser).

                                                    Если отбросить все исторические и архитектурные, то в случае IDE парсер должен уметь нечто, что парсеру в компиляторе в общем не нужно — кеш индексов на весь проект. Это необходимо для того, чтобы те же рефакторинги могли работать на всем проекте, а не только на том файле, где вызваны, с приемлемой производительностью.

                                                    То есть можно взять libclang, получить отличный код без false-positives и красного кода в редакторе, но потом с этим кодом будет ничего не сделать толком. Такой вариант нас не устраивает. Libclang, конечно, движется в сторону IDE, но пока простого варианта ее использования мы не видим.
                                                0
                                                Меня лично очень радует развитие поддержки Python. Какой ты проект на С++ не пиши с какого-то момента неприменно вылазит необходимость "вот тут и тут ма-а-а-ахонький скриптик бы на чём-то таком типа руби или питона". Отсутствие удобных средств что-то такое сделать меня очень напрягало в Visual Studio до появления Python Tools в её последних версиях. Радует, что CLion дошел до понимания данной проблемы значительно быстрее.
                                                  +1
                                                  А для Pycharm планируется Mark directory as -> Library files?

                                                  Чтобы рефакторинги не трогали 3rd party либы, которые валяются рядом, а не pip-ом установлены. Было бы хорошо.
                                                    0
                                                    Добрый день,
                                                    Для библиотек пока не планируется. Обычно они ставятся через pip и мы до сих пор не получали подобных запросов.
                                                    Вы можете завести реквест на эту функциональность здесь https://youtrack.jetbrains.com/issues/PY.
                                                    Мы рассмотрим это при планировании следующих релизов.
                                                    0
                                                    Хм, а это только у меня отвалился анализ кода в заголовочных файлах, подключенных через include_directories()? В предыдущей версии проблем с этом, кажется, не было.
                                                      0
                                                      Надо разбираться. Вероятно, потребуется проект или пример. Пишите в саппорт — будем изучать.
                                                    0
                                                    https://youtrack.jetbrains.com/issue/CPP-6221 вот вам ещё один баг. Третий за сегодня! Зачем отладчик сломали-то? Раньше хоть gdb консоль работала нормально, если что она выручала. А тут она моргает как не знаю что после пары ентеров. Также заметил что в корневой папке сборки под Linux лежит LLDBFrontend, но LLDB под Linux'ом пока нету, только под маком как я понимаю? Зачем тогда ложить его в папку? Подразнить народ?)) Давайте уже сделайте нормальный отладчик! Нам не фишки рефакторинга нужны, их мы можем и в виме сделать и clang static analyzer тоже есть, ваш пока тоже не алё. Нам нужен красивый, няшный, отказоустойчивый и отзывчивый отладчик + ещё кому-то вон удалённый нужный. Это задача номер один!!! Почему вы это до сих пор не поняли, понять не могу! Жду LLDB для Linux'а в общем!
                                                      0
                                                      Спасибо за репорт. Это на Линуксе, я правильно поняла? Дело не в дебагере, а вероятно в UI проблеме. Используется забандленная кастомная JRE или своя? Если забандленная, то попробуйте переключиться на свою (можно либо через Swift JDK свитчер через Find Action или выставить CL_JDK в environment). Поможет?
                                                      LLDBFrontend — это наш собственный драйвер для запуска Swift LLDB отладчика под Линуксом.
                                                      На дебагером мы работаем, и в текущем релизе пофиксили довольно много проблем. Не спорю, еще много осталось, — работа идет. Remote debug запланирован на следующий релиз.
                                                        0
                                                        Проверил на Oracle-8-jdk & openjdk-8-jdk. Никак не влияет на воспроизводимость бага. То есть для SWIFT LLDB у вас уже работает, а для С++ пока ещё нет? Странно, но для С++ он конечно нужнее.
                                                          0
                                                          Вероятно, проблема присутствует и в оракловой jdk. В любом случае, в нашей кастомизированной версии постараемся пофиксить как можно быстрее. Извините за неудобства.
                                                          Для Swift — LLDB единственный дебагер, а для C++ все же есть GDB. И сейчас поддержка Swift LLDB в CLion существенно ограничена по функционалу. Для C++ поддержка LLDB на Linux в CLion еще не готова, но работа идет.
                                                            0
                                                            И собственно такое предложение. Может поддержку LLDB постараться выпилить как-то как отдельный open source-проект? Это бы думаю пошло бы на пользу вам и люди могли бы дополнять быстрее нужны им функции + плюс лучший аудит кода. Тоже самое предложение могу внести и по поводу static analyzer'a. Было бы круто.
                                                              0
                                                              Спасибо за предложение. Мы подумаем. Правда, боюсь, что пока это довольно нетривиальная задача.
                                                                0
                                                                Понял. Ещё сразу тогда вопрос по функции Attach to local process. Запускаю своё приложение из консоли, оно зависает(где-то там deadlock), соответственно пытаюсь сделать сделать из Clion attach to local process. Но он выдаёт следующее: "
                                                                ptrace: Operation not permitted.
                                                                Debugger detached ".
                                                                Соответственно вопрос, что я делаю не так и как это исправить?
                                                                  0
                                                                  Комментарий вот здесь посмотрите. Это "защита" в Ubuntu by-design.
                                                      0
                                                      Не могу заставить работать свежеустановленный EAP CLion на работу в принципе. Вот тут все шаги прекрасно расписаны How to setup Clion for compile and RUN. Quick Start Guide ничего о проблемах при установке и первоначальной настройке не знает вообще.
                                                      Куда обращаться человеку с высоким коэффициентом кривизны рук?
                                                      0
                                                      Кстати, а почему необходимы лишние телодвижения по установке окружения Cygwin или MinGW? Или почему сама IDE не умеет грузить нужные ей версии компонентов для работы?
                                                      Тотже DataGrip умеет самостоятельно загружать недостающие компоненты.
                                                        0
                                                        Какие-то вещи CLion бандлит, но не все (cmake, gdb). Там лицензия не везде позволяет. Разве что можно подумать, чтобы IDE нужные компоненты через command-line установщик какой-то ставила.

                                                      Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                                      Самое читаемое