Комментарии 99
хочется dlang...
Баг с буфером обмена так и не пофиксили?
Мы пытаемся. Проблема в том, что нет надежного способа воспроизведения, что сильно усложняет задачу.
Видимо только мне не везет. Стабильно проявляется раз в примерно полчаса.
Может с обновлением лучше будет
Может с обновлением лучше будет
Если Вы сможете помочь со стабильным воспроизведением, будем вам очень благодарны. Отпишитесь в комментариях в тикете.
С Unreal Engine 4 по-прежнему не дружит?
А в чём именно они не дружат? Задаю вопрос, как человек, планирующий в течение года познакомиться с UE4 и никогда не использовавший CLion.
Что именно имеется в виду под "не дружит"? Мы обсуждали вот этом треде, какие есть возможности. Ничего специально в этом направлении не реализовывали.
Да, мы обсуждали в том треде (а потом ещё и с fsmorygo в скайпе) и в результате пришли к тому, что CLion не работает с UE4 вообще никак. В чём-то это проблема UE4, в котором самодельная тулза для генерации CMakeLists.txt, в чём-то это проблема CLion'а.
Но до сих пор тривиальный кейс вида «скачать UE4, Setup.sh, GenerateProjectFiles.sh, clion CMakeLists.txt» даёт на выходе неюзабельное нечто, в котором даже кнопку Build нажать нельзя, я уж не говорю о навигации по исходникам.
Только что перепроверил на CLion 2016.1 + UE4 4.11, ничего не изменилось.
Но до сих пор тривиальный кейс вида «скачать UE4, Setup.sh, GenerateProjectFiles.sh, clion CMakeLists.txt» даёт на выходе неюзабельное нечто, в котором даже кнопку Build нажать нельзя, я уж не говорю о навигации по исходникам.
Только что перепроверил на CLion 2016.1 + UE4 4.11, ничего не изменилось.
Да, коллеги напомнили мне, в чем там были проблемы. Похоже, что ситуацию спасет add_custom_target, который мы планируем поддержать в 2016.2
Было бы не плохо прикрутить его к AndroidStudio. Очень не хватает отладки NDK.
Есть какие-нибудь оценки по срокам, когда появится поддержка других систем сборки?
Тут история такая — мы думаем в сторону Makefiles. Но пока видим много проблем CMake модели. Если сейчас взяться за Makefile-ы, есть опасение, что эти же проблемы прорастут и в Makefiles. Поэтому мы хотим закончить важные вещи в CMake поддержке. Да и вообще негоже хвататься за вторую систему, не решив важных проблем в первой.
Думали, что в 2016.1 все критичные вещи в CMake закончим. Но, по ряду причин, не вышло.
Думали, что в 2016.1 все критичные вещи в CMake закончим. Но, по ряду причин, не вышло.
А вот с этим есть какие-то подвижки?
https://youtrack.jetbrains.com/issue/CPP-1028
https://intellij-support.jetbrains.com/hc/en-us/community/posts/206608365-CLion-and-MITK
https://youtrack.jetbrains.com/issue/CPP-1028
https://intellij-support.jetbrains.com/hc/en-us/community/posts/206608365-CLion-and-MITK
У вас очень странная политика разделения на продукты. т.е. 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.
Например, есть проект на… 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.
Давайnt по порядку:
2) планируется, просто задача не совсем первоочередная пока, поэтому отложена на несколько неопределенный срок. Надо бы хорошо понять, какие use case у такого.
3) есть
4) есть
Соб-но, веб фичи + С/С++ и Python/C/C++ нам кажутся наиболее частными случаями смешанного кода для C/C++. Поэтому они поддержаны. Остальные в порядке приоритетов.
Angular-а в CLion нет, но как-то никто и не просил пока особо.
2) планируется, просто задача не совсем первоочередная пока, поэтому отложена на несколько неопределенный срок. Надо бы хорошо понять, какие use case у такого.
3) есть
4) есть
Соб-но, веб фичи + С/С++ и Python/C/C++ нам кажутся наиболее частными случаями смешанного кода для C/C++. Поэтому они поддержаны. Остальные в порядке приоритетов.
Angular-а в CLion нет, но как-то никто и не просил пока особо.
Спасибо за ответ.
Но, кажется я неправильно сформулировал основную проблемы:
-"Не понятно что есть в какждой конкретной IDE"
-"Не понятно быстро выбрать нужный тебе набор"
Т.е. вы говорите "планируется, просто задача не совсем первоочередная" — я правильно понимаю, что есть какие-то технические ограничения? Всмысле, я переехал на ваши продуты с Eclipse и его устройство кажется логичным — Базовая платформа + Плагины для языков. Ваши продукты выглядят так, что кажется что они устроенны аналогично, и вопрос включать тот или иной плагин в IDE — для вас "организационный" а не технический. Ну и то, что All Products Pack стоит дешевле чем каждая IDE в отдельности — подтверждает эту догадку.
Так вот, про use case: я могу привести несколько:
И в тех случаях которые я видел — потребность возникает с первого языка. Т.е. человеку нужно только PHP, он покупает себе, допустим PHPStorm, а потом оказывается что ему нужны еще С++
Это очень странно. В смысле, если-бы у вас была базовая платформа (Вроде IDEA Community) и к ней можно было-бы докупать модули для языков-технологий (ну или бандл "все сразу в одной IDE") — это было-бы удобно, по крайней мере для тех разработчиков которых я знаю. А сейчас когда советуешь вашу IDE кому-то нельзя даже сказать "ну купи подписку на все" или "IDEA Ultimate тебе подойдет" потому что наверняка он наткнется на то, что ему прийдется открывать один проект в нескольких IDE.
Но, кажется я неправильно сформулировал основную проблемы:
-"Не понятно что есть в какждой конкретной 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.
Тут скорее архитектурный вопрос — переносить в плагин только C++ как языковую поддержку или с проектной моделью? В обоих случаях есть свои плюсы и минусы. И в любом случае, это потребует ресурсов, так как исторически CLion "начался" в AppCode, который не поставляется как плагин к IntelliJ IDEA.
Про кейс с PHP согласна — он относительно частый, мы уже про такой несколько раз слыхали.
iOS разработка — это AppCode, там С/С++ как раз из CLion (у них в этом месте общая кодовая база просто исторически)
JNI — вроде есть Android Studio (с C++ поддержкой на базе CLion)
В общем, наверное, основания для плагина и правда есть, просто пока у нас совсем нет ресурсов на эту задачу (и она не кажется первоочередной).
Про кейс с PHP согласна — он относительно частый, мы уже про такой несколько раз слыхали.
iOS разработка — это AppCode, там С/С++ как раз из CLion (у них в этом месте общая кодовая база просто исторически)
JNI — вроде есть Android Studio (с C++ поддержкой на базе CLion)
В общем, наверное, основания для плагина и правда есть, просто пока у нас совсем нет ресурсов на эту задачу (и она не кажется первоочередной).
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 или нет?
В IntelliJ IDEA соб-но нет всех языков — C/C++, Objective-C/Objective-C++, Swift. И нет проектной модели — CMake/Xcode. Что CLion, что AppCode довольно сильно повязаны на проектную модель, так как информация из нее используется для корректного парсинга и резолва. Поэтому перенести без проектной модели = сделать поддержку другой проектной модели, а мы пока не готовы к такому (ни по ресурсам, ни по ряду технических причин).
Про разнообразные проекты, для которых таки может понадобиться запустить CLion и еще какую-то нашу IDE, в целом я и не спорю. Да, есть такие случаи. Но опять же — это вопрос приоритетов.
Там, на самом деле, есть другая проблема. Запуск одновременно двух IDE наших на одном проекте приводит к тому, что они начинают показывать нотификацию и предлагать перезагрузить проект (отказаться можно, но это все равно действие какое-то). Что не удобно. Надеюсь, это мы скоро пофиксим.
Про разнообразные проекты, для которых таки может понадобиться запустить CLion и еще какую-то нашу IDE, в целом я и не спорю. Да, есть такие случаи. Но опять же — это вопрос приоритетов.
Там, на самом деле, есть другая проблема. Запуск одновременно двух IDE наших на одном проекте приводит к тому, что они начинают показывать нотификацию и предлагать перезагрузить проект (отказаться можно, но это все равно действие какое-то). Что не удобно. Надеюсь, это мы скоро пофиксим.
Спасибо.
Правильно-ли я понял, что остально — ( Python/PHP/JS/SQL ) в IDEA аналогично спецализированным IDE *Storm, DataGrip и т.д.?
А где у вас можно почитать про эту "проектную модель"?
А вот с этим я не сталкивался ни разу — обычно на разных языках все-таки написаны разные части проекта.
Правильно-ли я понял, что остально — ( Python/PHP/JS/SQL ) в IDEA аналогично спецализированным IDE *Storm, DataGrip и т.д.?
Поэтому перенести без проектной модели = сделать поддержку другой проектной модели, а мы пока не готовы к такому (ни по ресурсам, ни по ряду технических причин).
А где у вас можно почитать про эту "проектную модель"?
Там, на самом деле, есть другая проблема. Запуск одновременно двух IDE наших на одном проекте приводит к тому, что они начинают показывать нотификацию и предлагать перезагрузить проект (отказаться можно, но это все равно действие какое-то). Что не удобно. Надеюсь, это мы скоро пофиксим.
А вот с этим я не сталкивался ни разу — обычно на разных языках все-таки написаны разные части проекта.
Правильно-ли я понял, что остально — ( Python/PHP/JS/SQL ) в IDEA аналогично спецализированным IDE *Storm, DataGrip и т.д.?
В общем и целом да.
А где у вас можно почитать про эту "проектную модель"?
Открытого API у CLion на проектную модель нет, так что пока нигде.
обычно на разных языках все-таки написаны разные части проекта.
Даже при независимых частях, там достаточно иметь один общий проект с общей папкой настроек IDE, чтобы получить такие "конфликты". Вам видимо повезло.
По-видимому опечатка или неточность:
"Одна из самых долгожданных возможностей — отладка процесса, запущенного на локальной машине из IDE".
Это же изначально было! А долгожданная возможность — отладка процесса, запущенного ВНЕ IDE! Иными словами — Attach to Process.
Но и тут ложка дёгтя: если вдруг не получилось (не хватило прав), то с консоли я могу повторить попытку через sudo, а у вас — увы, без вариантов.
Про кодогенерацию — тоже не выглядит особо круто.
(разные VAssist умеют подобное).
Причина — всё рассчитано по дефолту на паттерн — класс объявлен в файле класс.h(pp), определён в файле класс.cpp
Но! В реальной жизни всё может быть далеко не так! (может и неудобно, но наследие… Равно как и файлы размером >512000 байт. Последние нахрапом пользователей принУдили победить… А как с именами? Тоже нужно брут форс в багтреккер, или можно "на берегу" договориться?)
Ведь вроде очень просто же — видим объявление класса; смотрим, где оно — и рисуем меню. Если оно прямо в cpp — то это очевидно класс для внутреннего пользования, можно или вообще ничего не делать, или предложить какое-то дефолтное меню.
Если в хедере класс.h — то либо как сейчас, либо усложняем дальше.
Если "в каком-то хедере" (никакой корелляции с именем класса) — то тут уже "умный" выбор — добавить определение прямо в хедер (очевидно), добавить определение в <выпадающее меню .cpp-файлов проекта> (капельку сложнее), либо — по аналогии с пометкой папок — добавить пометки (=тэги, =связи) к хедерам — "классы, объявленные здесь, определяются в source1.cpp, source2.cpp… sourceN.cpp" — и именно эти файлы как варианты предлагать в меню выбора местоположения определений членов очередного объявленного в хедере класса.
Дальнейшая умность — эти самые возможные исходники определять самостоятельно (включив в список файлы, где уже живут определения объявленных в данном хедере классов). И выделять приоритетным (в верху списка вариантов) исходник, где определено подавляющее большинство членов того класса, где мы пытаемся объявить новый член.
"Одна из самых долгожданных возможностей — отладка процесса, запущенного на локальной машине из IDE".
Это же изначально было! А долгожданная возможность — отладка процесса, запущенного ВНЕ IDE! Иными словами — Attach to Process.
Но и тут ложка дёгтя: если вдруг не получилось (не хватило прав), то с консоли я могу повторить попытку через sudo, а у вас — увы, без вариантов.
Про кодогенерацию — тоже не выглядит особо круто.
(разные VAssist умеют подобное).
Причина — всё рассчитано по дефолту на паттерн — класс объявлен в файле класс.h(pp), определён в файле класс.cpp
Но! В реальной жизни всё может быть далеко не так! (может и неудобно, но наследие… Равно как и файлы размером >512000 байт. Последние нахрапом пользователей принУдили победить… А как с именами? Тоже нужно брут форс в багтреккер, или можно "на берегу" договориться?)
Ведь вроде очень просто же — видим объявление класса; смотрим, где оно — и рисуем меню. Если оно прямо в cpp — то это очевидно класс для внутреннего пользования, можно или вообще ничего не делать, или предложить какое-то дефолтное меню.
Если в хедере класс.h — то либо как сейчас, либо усложняем дальше.
Если "в каком-то хедере" (никакой корелляции с именем класса) — то тут уже "умный" выбор — добавить определение прямо в хедер (очевидно), добавить определение в <выпадающее меню .cpp-файлов проекта> (капельку сложнее), либо — по аналогии с пометкой папок — добавить пометки (=тэги, =связи) к хедерам — "классы, объявленные здесь, определяются в source1.cpp, source2.cpp… sourceN.cpp" — и именно эти файлы как варианты предлагать в меню выбора местоположения определений членов очередного объявленного в хедере класса.
Дальнейшая умность — эти самые возможные исходники определять самостоятельно (включив в список файлы, где уже живут определения объявленных в данном хедере классов). И выделять приоритетным (в верху списка вариантов) исходник, где определено подавляющее большинство членов того класса, где мы пытаемся объявить новый член.
Это же изначально было! А долгожданная возможность — отладка процесса, запущенного ВНЕ IDE!
Запятая пропущена. Спасибо. Конечно, имелось в виду, что в IDE можно теперь отлаживать процесс, запущенный отдельно от IDE на локальной машине. Пишите баги в трекер — функционал новый, уверена, что мы его будем совершенствовать.
А как с именами? Тоже нужно брут форс в багтреккер, или можно "на берегу" договориться?
Не очень поняла, о чем речь.
Про кодогенерацию — вообще много интересных идей Вами описано. Тут главное найти баланс — между сложностью интерфейса, логичностью действий по умолчанию и желанию покрыть как можно больше вариантов использования.
Мы сейчас собрали достаточно фидбека и у нас (как нам кажется) есть хорошее понимание того, в каких случаях текущая логика может не подходить, и что с этим можно сделать. Часть изменений по usability кодогенерации попала в этот релиз, остальные ожидаются в ближайшем будущем (в том числе перекликающиеся с предложенными идеями).
Пытался когда-то попользоваться этой IDE, но её жёсткая привязанность к CMake сразу делает её бесполезной для множества проектов. В мире C/C++ среда сборки бывает очень разношёрстной, привязываться к какой-то одной — фатальный недостаток. Поддержка мейкфайлов тут тоже не очень поможет. Мне не в лом компилировать из командной строки (в некоторых проектах среда компиляции вообще бывает настроена на специальных сборочных серверах, и у разработчиков нет возможности компилировать и запускать бинарники локально, чувствуется влияние Java и т.п. технологий, но C/C++ — это совершенно из другой оперы). Хочется иметь удобную IDE, с качественной индексацией и прочими прелестями для удобной работы с кодом, совершенно не обязательна поддержка сборки в ней. После опыта использования IDEA с джавой были большие ожидания от clion, но ждало горькие разочарование. В ней действительно нельзя настроить вручную пути к заголовкам и символы препроцессора или я плохо искал? (до сих пор не могу в это поверить).
НЛО прилетело и опубликовало эту надпись здесь
Понимаю все аргументы, но тут расчет был прост — надо откуда-то было брать кучу информации для парсера и резолва, чтобы IDE делала это максимально корректно. Но откуда? Варианты были либо писать свой формат проекта, либо брать существующий. Взяли в итоге существующий. При чем CMake не только один из самых популярных форматов для кросс-платформенных проектов, это же еще и агрегатор множества известных генераторов (он умеет и Makefile, и VS, итд).
Теперь про будущее. Конечно, мы тоже хотим, чтобы CLion позволял просто открыть папку с исходным кодом. И чтобы можно было просто вручную прописать пути к заголовкам, и пр. Это такой универсальный API над тем, что у нас сейчас для CMake сделано. И вообще он в мыслях/планах есть. Просто надо сначала текущие критичные проблемы с одной билд-системой порешать, прежде чем за такую унификацию браться. Нам так, по-крайней мере, кажется.
Теперь про будущее. Конечно, мы тоже хотим, чтобы CLion позволял просто открыть папку с исходным кодом. И чтобы можно было просто вручную прописать пути к заголовкам, и пр. Это такой универсальный API над тем, что у нас сейчас для CMake сделано. И вообще он в мыслях/планах есть. Просто надо сначала текущие критичные проблемы с одной билд-системой порешать, прежде чем за такую унификацию браться. Нам так, по-крайней мере, кажется.
И правильно сделали. Несмотря на обилие систем сборок для плюсовых проектов, в реальности право на жизнь имеют, имхо, только cmake, waf и qbs. Начинать писать сейчас проект на Makefile или Visual Studio Project, мягко говоря, очень странно.
С другой стороны, перетащить любой проект (Makefile, например) на тот же cmake — проблема скорее минут, нежели часов. Даже портирование таких монстров, как GDAL и Xerces-C++, заняло в свое время у меня пару часов.
Так что лично мне непонятно это нытье насчет поддержки множества систем сборок. Ну т.е. в этом нет ничего плохого, но есть куда более важные вещи, которые хочется видеть в современной IDE (типа поддержки Valgrind, которую от вас уже джва года ждут).
С другой стороны, перетащить любой проект (Makefile, например) на тот же cmake — проблема скорее минут, нежели часов. Даже портирование таких монстров, как GDAL и Xerces-C++, заняло в свое время у меня пару часов.
Так что лично мне непонятно это нытье насчет поддержки множества систем сборок. Ну т.е. в этом нет ничего плохого, но есть куда более важные вещи, которые хочется видеть в современной IDE (типа поддержки Valgrind, которую от вас уже джва года ждут).
Спасибо.
Про Valgrind — это, действительно, запрос еще со времен private preview, и мы даже думали про него в 2016.1, но не сложилось. Надеемся, что уже скоро сможем и его добавить.
Про Valgrind — это, действительно, запрос еще со времен private preview, и мы даже думали про него в 2016.1, но не сложилось. Надеемся, что уже скоро сможем и его добавить.
Вряд ли крупный опенсорсный проект согласиться сменить систему сборки только из-за того вы пользуетесь IDE которая поддерживает только CMake.
Имеют или не имеют права на жизнь вопрос другой, но используются повсеместно и поддерживаться IDE должны имхо.
С другой стороны, для меня очень есть фичи и поважнее системы сборки, типа того же Valgrind и gprof. Развиваться есть куда, ребята работают над проектом, так что терпеливо ждем -_-
Имеют или не имеют права на жизнь вопрос другой, но используются повсеместно и поддерживаться IDE должны имхо.
С другой стороны, для меня очень есть фичи и поважнее системы сборки, типа того же Valgrind и gprof. Развиваться есть куда, ребята работают над проектом, так что терпеливо ждем -_-
Если makefile используется на всю мощь и рекурсивно, то перенос на cmake будет очень долгим и болезненным.
НЛО прилетело и опубликовало эту надпись здесь
Ээээ… вы точно в курсе, что такое система сборки в мире C++? И зачем она вообще нужна, если можно просто брать из "системных путей, либо оттуда, откуда написал пользователь"?
Какие в мире C++ есть преимущества у maven по сравнению с cmake?
Какие в мире C++ есть преимущества у maven по сравнению с cmake?
НЛО прилетело и опубликовало эту надпись здесь
Да, я в курсе. Я говорил про анализ кода и навигацию по нему, когда сказал, что достаточно иметь сам код и используемые им хедера. Компилятору этого достаточно и без 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 и дофига всего еще.
На сегодня просто нет альтернатив по функционалу.
НЛО прилетело и опубликовало эту надпись здесь
На самом деле, cmake все-таки позволяет собрать проект двумя командами на любой платформе. Сначала вы генерируете проект обычным способом, а затем используете команду cmake --build. для сборки. Для каждого генератора будет выполнен соответствующий ему сборщик, например для Visual Studio это будет MSBuild, а на Unix это будет, например, Make.
Это если все это установлено на билд хосте. А если нет? Иногда нужно линковать с чем-то, что не хочется или нельзя ставить в систему.ExternalProject разве не решает эту проблему? Если какие-то зависимости отсутствуют в системе, их можно подключить в виде ExternalProject-зависимостей, которые будут загружены при сборке либо в виде уже готовых библиотек, либо в виде исходного кода, собираемого перед сборкой основных целей.
Конечно, это может сильно усложнить, раздуть и запутать конфигурацию сборки проекта, но бывает и довольно удобно сделать такой «Superbuild» для проекта с развесистым списком зависимостей.
Кстати, CLion, вроде, такие штуки не поддерживает. :(
Руки не дошли пока протестить хорошо, но вроде пользователи пишут, что работает. В ближайшее время, надеюсь, доберемся проверить/дофиксить.
К сожалению CMake очень не гибкое средство. Как настроить билд компиляторами не поддерживаемыми из коробки я так и не смог понять. Судя по всему единственный способ — делать форк CMake'a. В результате пишу одновременно Makefile и CMakeLists.txt: первый для билда, второй для CLion :((
Насколько я понимаю оно позволяет настроить пути к компилятору, но я не вижу способов настроить способ передачи опций компилятору. Т.е. оно всё равно будет считать что компилятор GCC-совместимый. Хотя мой тулчейн (Synopsys VCS) и содержит внутри себя GCC, но собираются проекты всё равно слегка иначе.
Я пытался вытащить через переменные CMake списки исходников, пути к либам и пр. а затем собирать проект с помощью add_custom_command и add_custom_target. Но в итоге решил что проще будет писать Makefile и CMakeLists.txt
Надеюсь что в Clion в итоге сделают поддержку ручной настройки проека (как в Eclipse CDT) и я смогу спокойно обходится одними Makefiles.
Я пытался вытащить через переменные CMake списки исходников, пути к либам и пр. а затем собирать проект с помощью add_custom_command и add_custom_target. Но в итоге решил что проще будет писать Makefile и CMakeLists.txt
Надеюсь что в Clion в итоге сделают поддержку ручной настройки проека (как в Eclipse CDT) и я смогу спокойно обходится одними Makefiles.
Есть возможность настроить флаги в toolchain-файле, например вот так:
Вообще, в CMake все стандартные тулчейны настраиваются обычными cmake-скриптами, которые лежат в "<путь-установки>/share/cmake/Modules" (большинство из них — в директориях Compiler и Platform) и там можно почерпнуть много информации. Но скрипты там не очень очевидные и да, я согласен, что это очень плохо документировано.
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) и там можно почерпнуть много информации. Но скрипты там не очень очевидные и да, я согласен, что это очень плохо документировано.
Спасибо! Начал копать.
Пока оно у меня валится на compiler check, точнее на линковке. Потому что VCS предполагает что функция main будет называться sc_main. Следовательно падает всё на undefined reference to `sc_main'
Как настроить ему исходники для проверки компилятора я пока не понял.
Пока оно у меня валится на compiler check, точнее на линковке. Потому что VCS предполагает что функция main будет называться sc_main. Следовательно падает всё на undefined reference to `sc_main'
Как настроить ему исходники для проверки компилятора я пока не понял.
Всё, Hello world мне удалось собрать.
Выключил проверку компиляторов с помощью
set(CMAKE_CXX_COMPILER_FORCED TRUE)
set(CMAKE_C_COMPILER_FORCED TRUE)
Выключил проверку компиляторов с помощью
set(CMAKE_CXX_COMPILER_FORCED TRUE)
set(CMAKE_C_COMPILER_FORCED TRUE)
НЛО прилетело и опубликовало эту надпись здесь
Есть ли планы относительно поддержки удаленного компилятора и отладчика? Типичный use-case, когда разработка проекта ведется на MacOS X, а сборка и тестирование на Linux VM \ Remote server. Ставить десктопный Linux ради разработки и сборки на одном окружении не всегда представляется удобным и\или возможным.
Есть. Соб-но, attach to local process первый шаг в направлении remote debug. Ну и компиляция там тоже где-то. Запрос к трекере — CPP-744
Скажите, а владельцу Perpetual License на предыдущую версию, пару недель назад ее продлившему, снова нужно платить за новую версию? Спасибо.
Если у Вас есть действующая подписка (а раз Вы ее недавно продлили, то, вероятно, есть) на CLion, то ничего дополнительно платить не надо.
Спасибо! К сожалению, пришлось сразу откатиться на старую версию, в связи с полной потерей совместимости. Создал баг https://youtrack.jetbrains.com/issue/CPP-6164, надеюсь на скорый фикс.
Хотеть поддержку сборки удаленных проектов по ssh! :)
А в таком случае проект полностью лежит удаленно? То есть как предполагается с ним работать — полностью по сети или копировать сорсы на локальную машину?
Доступ к файлам, разумеется, есть, силами 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 гигабит данных либо является встраиваемым устройством :)
Я себе это вижу как настраиваемый путь к команде сборки. Чтобы, например, вместо cmake… и make делать соотвественно: ssh remote_server_ip "cmake .." и ssh remote_server_ip "make".
На С и С++ сейчас редко пишут под десктоп, поэтому у Вас в тикете с описанием сабжа очень высокая активность. На своей машине при всем желании я не могу иметь софт, который проворачивает 40 гигабит данных либо является встраиваемым устройством :)
НЛО прилетело и опубликовало эту надпись здесь
IDE туда предлагает добавить файлы при создании (но это опционально, и можно галочку в диалоге отключить). Вроде больше никак не трогает CMakeLists.txt. Что имеется в виду?
НЛО прилетело и опубликовало эту надпись здесь
Папку build можно настроить с помощью
set(CMAKE_RUNTIME_OUTPUT_DIRECTORY "${CMAKE_CURRENT_SOURCE_DIR}/build")
set(CMAKE_RUNTIME_OUTPUT_DIRECTORY "${CMAKE_CURRENT_SOURCE_DIR}/build")
Про .build — сейчас нельзя сменить директорию, где запускается команда cmake. Можно только сменить директорию, куда копируются артифакты сборки. И хотя так было сделано by design, мы задумываемся, чтобы все же это изменить.
Так дело то не в сборке. Запуск cmake и понимание cmake файлов нужны ровно для того, чтобы навигация, автоополнение и др. "умные" фишки редактора работали корректно. Нужно понимать, какие и где заголовочные файлы, какие переменные в CMake определены, какой стандарт языка используется, и пр.
Мне бы хотелось по рабоче-крестьянски просто навигацию по коду и автокомплит в редакторе. Цены бы не было. А сборку я уж сам, из консоли.
Так дело то не в сборке. Запуск cmake и понимание cmake файлов нужны ровно для того, чтобы навигация, автоополнение и др. "умные" фишки редактора работали корректно. Нужно понимать, какие и где заголовочные файлы, какие переменные в CMake определены, какой стандарт языка используется, и пр.
Во многих случаях clion показывает ошибку в коде, где её на самом деле нет — я так понимаю, из-за какого-то упрощённого парсера, который не воспринимает некоторые возможности языка. Например — даже из туториала по boost (http://www.boost.org/doc/libs/1_60_0/more/getting_started/unix-variants.html, пункт 4) программа с использованием бустовской лямбды. Ещё из того, что у себя заметил — подсвечивает ошибками определение и использование суффиксов (которые user-defined literal из C++11), или например применение | к значениям enum'а иногда.
Кажется, что это не проблема нескольких частных случаев, а достаточно общая.
Кажется, что это не проблема нескольких частных случаев, а достаточно общая.
User defined литералы пока не поддерживаются.
Остальные ошибки можно (и даже нужно) репортить к нам в трекер. Мы будем их исправлять.
Остальные ошибки можно (и даже нужно) репортить к нам в трекер. Мы будем их исправлять.
А что используется для подсветки ошибок? Из-за того, что появляются такие баги, можно предположить что какое-то своё решение — собственно, почему не clang например?
Парсер — свой. Причин — много (я их как-то описывала вот здесь в разделе C++ parser).
Если отбросить все исторические и архитектурные, то в случае IDE парсер должен уметь нечто, что парсеру в компиляторе в общем не нужно — кеш индексов на весь проект. Это необходимо для того, чтобы те же рефакторинги могли работать на всем проекте, а не только на том файле, где вызваны, с приемлемой производительностью.
То есть можно взять libclang, получить отличный код без false-positives и красного кода в редакторе, но потом с этим кодом будет ничего не сделать толком. Такой вариант нас не устраивает. Libclang, конечно, движется в сторону IDE, но пока простого варианта ее использования мы не видим.
Если отбросить все исторические и архитектурные, то в случае IDE парсер должен уметь нечто, что парсеру в компиляторе в общем не нужно — кеш индексов на весь проект. Это необходимо для того, чтобы те же рефакторинги могли работать на всем проекте, а не только на том файле, где вызваны, с приемлемой производительностью.
То есть можно взять libclang, получить отличный код без false-positives и красного кода в редакторе, но потом с этим кодом будет ничего не сделать толком. Такой вариант нас не устраивает. Libclang, конечно, движется в сторону IDE, но пока простого варианта ее использования мы не видим.
Меня лично очень радует развитие поддержки Python. Какой ты проект на С++ не пиши с какого-то момента неприменно вылазит необходимость "вот тут и тут ма-а-а-ахонький скриптик бы на чём-то таком типа руби или питона". Отсутствие удобных средств что-то такое сделать меня очень напрягало в Visual Studio до появления Python Tools в её последних версиях. Радует, что CLion дошел до понимания данной проблемы значительно быстрее.
НЛО прилетело и опубликовало эту надпись здесь
Добрый день,
Для библиотек пока не планируется. Обычно они ставятся через pip и мы до сих пор не получали подобных запросов.
Вы можете завести реквест на эту функциональность здесь https://youtrack.jetbrains.com/issues/PY.
Мы рассмотрим это при планировании следующих релизов.
Для библиотек пока не планируется. Обычно они ставятся через pip и мы до сих пор не получали подобных запросов.
Вы можете завести реквест на эту функциональность здесь https://youtrack.jetbrains.com/issues/PY.
Мы рассмотрим это при планировании следующих релизов.
Хм, а это только у меня отвалился анализ кода в заголовочных файлах, подключенных через include_directories()? В предыдущей версии проблем с этом, кажется, не было.
https://youtrack.jetbrains.com/issue/CPP-6221 вот вам ещё один баг. Третий за сегодня! Зачем отладчик сломали-то? Раньше хоть gdb консоль работала нормально, если что она выручала. А тут она моргает как не знаю что после пары ентеров. Также заметил что в корневой папке сборки под Linux лежит LLDBFrontend, но LLDB под Linux'ом пока нету, только под маком как я понимаю? Зачем тогда ложить его в папку? Подразнить народ?)) Давайте уже сделайте нормальный отладчик! Нам не фишки рефакторинга нужны, их мы можем и в виме сделать и clang static analyzer тоже есть, ваш пока тоже не алё. Нам нужен красивый, няшный, отказоустойчивый и отзывчивый отладчик + ещё кому-то вон удалённый нужный. Это задача номер один!!! Почему вы это до сих пор не поняли, понять не могу! Жду LLDB для Linux'а в общем!
Спасибо за репорт. Это на Линуксе, я правильно поняла? Дело не в дебагере, а вероятно в UI проблеме. Используется забандленная кастомная JRE или своя? Если забандленная, то попробуйте переключиться на свою (можно либо через Swift JDK свитчер через Find Action или выставить CL_JDK в environment). Поможет?
LLDBFrontend — это наш собственный драйвер для запуска Swift LLDB отладчика под Линуксом.
На дебагером мы работаем, и в текущем релизе пофиксили довольно много проблем. Не спорю, еще много осталось, — работа идет. Remote debug запланирован на следующий релиз.
LLDBFrontend — это наш собственный драйвер для запуска Swift LLDB отладчика под Линуксом.
На дебагером мы работаем, и в текущем релизе пофиксили довольно много проблем. Не спорю, еще много осталось, — работа идет. Remote debug запланирован на следующий релиз.
Проверил на Oracle-8-jdk & openjdk-8-jdk. Никак не влияет на воспроизводимость бага. То есть для SWIFT LLDB у вас уже работает, а для С++ пока ещё нет? Странно, но для С++ он конечно нужнее.
Вероятно, проблема присутствует и в оракловой jdk. В любом случае, в нашей кастомизированной версии постараемся пофиксить как можно быстрее. Извините за неудобства.
Для Swift — LLDB единственный дебагер, а для C++ все же есть GDB. И сейчас поддержка Swift LLDB в CLion существенно ограничена по функционалу. Для C++ поддержка LLDB на Linux в CLion еще не готова, но работа идет.
Для Swift — LLDB единственный дебагер, а для C++ все же есть GDB. И сейчас поддержка Swift LLDB в CLion существенно ограничена по функционалу. Для C++ поддержка LLDB на Linux в CLion еще не готова, но работа идет.
И собственно такое предложение. Может поддержку LLDB постараться выпилить как-то как отдельный open source-проект? Это бы думаю пошло бы на пользу вам и люди могли бы дополнять быстрее нужны им функции + плюс лучший аудит кода. Тоже самое предложение могу внести и по поводу static analyzer'a. Было бы круто.
Спасибо за предложение. Мы подумаем. Правда, боюсь, что пока это довольно нетривиальная задача.
Понял. Ещё сразу тогда вопрос по функции Attach to local process. Запускаю своё приложение из консоли, оно зависает(где-то там deadlock), соответственно пытаюсь сделать сделать из Clion attach to local process. Но он выдаёт следующее: "
ptrace: Operation not permitted.
Debugger detached ".
Соответственно вопрос, что я делаю не так и как это исправить?
ptrace: Operation not permitted.
Debugger detached ".
Соответственно вопрос, что я делаю не так и как это исправить?
Комментарий вот здесь посмотрите. Это "защита" в Ubuntu by-design.
Не могу заставить работать свежеустановленный EAP CLion на работу в принципе. Вот тут все шаги прекрасно расписаны How to setup Clion for compile and RUN. Quick Start Guide ничего о проблемах при установке и первоначальной настройке не знает вообще.
Куда обращаться человеку с высоким коэффициентом кривизны рук?
Куда обращаться человеку с высоким коэффициентом кривизны рук?
Кстати, а почему необходимы лишние телодвижения по установке окружения Cygwin или MinGW? Или почему сама IDE не умеет грузить нужные ей версии компонентов для работы?
Тотже DataGrip умеет самостоятельно загружать недостающие компоненты.
Тотже DataGrip умеет самостоятельно загружать недостающие компоненты.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Релиз CLion 2016.1: новые инструменты и новые языки