Здравствуйте, alex_public, Вы писали:
_>Для cmake действительно не надо, но для других то так не получится. А я думал что они там некий обобщённый подход разработали для работы с чужими системами сборки (раз уж от своих настроек проекта отказались).
Дело в том, что от системы сборки им нужно две вещи — собственно собирать проект и получать метаданные о его структуре, желательно статическим анализом.
Для make/qmake/nmake/autohell — второй пункт, вообще говоря, невозможен даже для простейших проектов. Так что там остаётся только возможность вручную задавать структуру в том или ином виде, и просто запускать внешний инструмент для постройки. Такая поддержка уже появилась в зайчаточном состоянии в текущем EAP.
Добрый день, давайте по порядку разбираться:
_>1. Сразу бросилось в глаза, что CLion не сообщает Windows о том, что он умеет сам нормально работать с нестандартным DPI.
Есть такая проблема пока, в платформе. Например, вот это ишью https://youtrack.jetbrains.com/issue/IDEA-117729. Со временем, надеюсь, поправим.
_>2. Захотелось открыть файл и сразу поразился диалогу для этого. Он не просто совсем не стандартный, но похоже что и ещё не умеет видеть сеть (или я не увидел где это включается?).
Вроде должно работать, напиши ишью с описанием, если нет так.
_>4. А где локализация? ) Понятно что для программистов это вопрос совершенно не принципиальный. Но с учётом того, что даже мелкие бесплатные редакторы (типа Notepad++) имеют локазализацию (причём работающую по умолчанию), а во всех сравнимых конкурентах (Netbeans, Eclipse, Visual Studio) это уже давно работает, то несколько удивляет. Тем более, что уж для русской версии переводчиков точно не пришлось бы нанимать. )))
Пока что локализации не предвидится. Все термины из области разработки давно всем привычны на английском, подбирать аналоги на русском будет стоит больших усилий, а степень понимания все равно будет низкая. Потому что общеупотребительных терминов не так много. Ну, или это будет выглядеть как английские термины, но русскими буквами. Мы пока что раздумываем над этой возможностью, но хорошего решения не придумали.
_>Ну а дальше я перешёл к изучению системы проектов и тут уже пошёл ужас — её просто не оказалось в IDE вообще. Ну точнее она вся перенесена в сторонний инструмент (чужую систему сборки cmake).
Почему мы выбрали CMake довольно подробно отвечали вот здесь: http://blog.jetbrains.com/clion/2014/09/cmake-vs-the-others-round-1/ В целом нам и правда CMake кажется очень удобным инструментом, дающим разработчикам широкие возможности.
В целом планируем поддержать и другие системы сборки, но не в версии 1.0. Сейчас добавлена еще возможность импортировать существующий проект в CMake. Это, конечно, не замена другим системам сборки, но хоть что-то.
_>Но ещё больше чудес открылось, когда я перешёл к сборке... И тут дело совсем не в её архитектуре. Ну да, cmake, не лучшая система сборки, но и далеко не худшая. Ну да, зашита намертво и поддерживается только она одна. Но это вроде как только пока и обещают изменить к релизу. Всё дело в том, как тут cmake используется! Оно зачем-то создаёт папки (да, не одну, а сразу 5: default, Release, Debug, RelWithDebInfo, MinSizeRel — зачем???) для построения cmake'ом не в каталоге проекта, а где-то в домашнем каталоге пользователя (типа ~\.clion10\system\cmake\generated\7c448f19\7c448f19\)!
CLion сразу генерирует разные конфигурации (те самые Release, Debug, RelWithDebInfo, MinSizeRel), чтобы потом, работая в IDE, можно было на лету между ними переключаться, в частности выбирая соответствующий resolve context, и CLion будет в соответствии с этой конфигурацией анализировать/раскрашивать/резолвить код. Перестраивать эти конфигурации при выборе — долго и не удобно, поэтому стараемся их собрать сразу. Поэтому директория, в которой cmake запускается, она специфичная.
Соглашусь, что имеются потенциальные проблемы и тонкости, которые Вы описываете. Обсудим их с командой. Спасибо.
Здравствуйте, anastasiak2512, Вы писали:
_>>1. Сразу бросилось в глаза, что CLion не сообщает Windows о том, что он умеет сам нормально работать с нестандартным DPI. A>Есть такая проблема пока, в платформе. Например, вот это ишью https://youtrack.jetbrains.com/issue/IDEA-117729. Со временем, надеюсь, поправим.
В принципе, если не считать мелких иконок, CLion сам по себе нормально работает в любом dpi (оно и понятно, шрифты то в нём настраиваются). Проблема в том, что он почему-то не сообщает об этом windows. Хотя делается это тривиально, например с помощью манифеста.
_>>2. Захотелось открыть файл и сразу поразился диалогу для этого. Он не просто совсем не стандартный, но похоже что и ещё не умеет видеть сеть (или я не увидел где это включается?). A>Вроде должно работать, напиши ишью с описанием, если нет так.
и где здесь сеть?
Для сравнения такое же окно Netbeans'a (тоже Java): — конечно тоже ерунда, по сравнению со стандартным окном винды, но во всяком случае все необходимые элементы имеются.
Да, если что, у меня там в "сети" сидит как минимум nas с архивом (в том числе и проектов, так что иногда надо открывать).
A>Пока что локализации не предвидится. Все термины из области разработки давно всем привычны на английском, подбирать аналоги на русском будет стоит больших усилий, а степень понимания все равно будет низкая. Потому что общеупотребительных терминов не так много. Ну, или это будет выглядеть как английские термины, но русскими буквами. Мы пока что раздумываем над этой возможностью, но хорошего решения не придумали.
Рекомендую хоть раз открыть Netbeans или Eclipse и увидеть нормальные и всем понятные термины на русском. Кстати, а на этом форуме мы разве общаемся на английском языке?
A>Почему мы выбрали CMake довольно подробно отвечали вот здесь: http://blog.jetbrains.com/clion/2014/09/cmake-vs-the-others-round-1/ В целом нам и правда CMake кажется очень удобным инструментом, дающим разработчикам широкие возможности. A>В целом планируем поддержать и другие системы сборки, но не в версии 1.0. Сейчас добавлена еще возможность импортировать существующий проект в CMake. Это, конечно, не замена другим системам сборки, но хоть что-то.
Ещё раз повторю свою точку зрения (и уверен, что её придерживается большинство): я не собираюсь переходить на другую (причём в моём случае более слабую) систему сборки ради чуть лучшего редактора. Так что получается сейчас весь ваш проект интересен только людям или уже использующим cmake или использующим встроенную в старую ide систему сборки.
Почему нельзя было просто сделать возможность запуска произвольной команды для построения — это для меня загадка. Такое есть вообще везде, даже не в ide, в обычных редакторах.
A>CLion сразу генерирует разные конфигурации (те самые Release, Debug, RelWithDebInfo, MinSizeRel), чтобы потом, работая в IDE, можно было на лету между ними переключаться, в частности выбирая соответствующий resolve context, и CLion будет в соответствии с этой конфигурацией анализировать/раскрашивать/резолвить код. Перестраивать эти конфигурации при выборе — долго и не удобно, поэтому стараемся их собрать сразу. Поэтому директория, в которой cmake запускается, она специфичная. A>Соглашусь, что имеются потенциальные проблемы и тонкости, которые Вы описываете. Обсудим их с командой. Спасибо.
Даже если действительно нужно создавать все эти каталоги сразу, то не вижу никаких проблем делать это в каталоге проекта. Всё равно же вы мусорите туда (.idea).
Здравствуйте, vpchelko, Вы писали:
V>Ага VS с русской локализацией. это ужас. Эти дебилы локализовали сообщения компилятора и линкера. V>Я вот совсем недавно узнал, что такое "компоновка".
Ну лично я вообще против засилья англицизмов в русском языке. ) Хотя при этом английским владею свободно. Но это не повод не уметь разговаривать с коллегами на родном языке.
Здравствуйте, Cyberax, Вы писали:
C>В QTCreator есть два режима — с моделью кода на clang и их собственной.
C>По умолчанию стоит их собственная — она работает очень быстро, но неточно. Если поставить clang'овскую, то автодополнение и подсветка ошибок начинают работать идеально (я не нашёл ни единой ошибки в сложном коде). Но до ужаса медленно, но моём лэптопе показ вариантов дополнения занимает секунду-две в лучше случае (в худшем до 10 секунд).
Воот, у меня были точно такие же воспоминания про clang (правда не в Qt Creator). Но niXman сказал что вроде как оно теперь мгновенное... Ну попробую проверить конечно, вдруг случилось чудо. )
Здравствуйте, Cyberax, Вы писали:
C>Дело в том, что от системы сборки им нужно две вещи — собственно собирать проект и получать метаданные о его структуре, желательно статическим анализом.
Оставили бы второе в настройках IDE и не было бы никаких проблем.
C>Для make/qmake/nmake/autohell — второй пункт, вообще говоря, невозможен даже для простейших проектов.
Теоретически возможно в режиме "виртуального прогона". Но это будет стоит очень больших усилий, причём потребуется отдельная виртуальная система для каждой системы. Т.е. по сути надо написать заново движки для 10-15 главных систем сборки. Сомневаюсь что осилят.
C>Так что там остаётся только возможность вручную задавать структуру в том или ином виде, и просто запускать внешний инструмент для постройки. Такая поддержка уже появилась в зайчаточном состоянии в текущем EAP.
Ээээ где она там? В упор не вижу. Единственное что есть, это "External Tools", но это как бы совсем другое дело.
C>>Да, прокрутка без подгонки курсора к краю — ctrl+стрелки или обычные pgup/pgdown.
MTD>Сразу видно настоящих логов ты не видал, руки отсохнут ctrl+стрелки делать.
Здравствуйте, alex_public, Вы писали:
_>Причём главное что я не понимаю смысла этого гениального решения — какой вообще может быть аргумент в пользу подобного извращения? Да, а в какой-нибудь IDE такое вообще встречалось? Я вот что-то не припомню.
Здравствуйте, alex_public, Вы писали:
_>Здравствуйте, Zhendos, Вы писали:
Z>>Не совсем понял вашу идею, допустим у cmake есть 50%, а остальное делят autotools, qmake и остальные.
_>В том то и дело, что там совсем не 50%. Об этом и была речь. Т.е. в данной области можно быть лидером, не набирая даже и 30% популярности. Собственно поэтому IDE поддерживающая одну систему сборки и выглядит странно.
А откуда цифры? Скажем на stackoverflow я время от времени вижу вопросы про cmake, намного реже про qmake,
и совсем не видел про python based.
Z>>Мне скажем удобно, т.к. исходники я держу на SSD, а директорию для сборки в RAM, поэтому сделал symlink на /tmp, который у меня Z>>в RAM смонтирован и вот уже clion настроен в соотвествии с моими предпочтениями. Возможно это довольно популярный сценария использования.
_>Нуу в принципе тоже вариант. А не смущает, что нельзя будет в будущем просто взять из проекта результат построения (придётся строить заново и потом копировать из /tmp)?
Не совсем понял, имеется ввиду, если я перезагружусь, то придется все перестраивать?
Т.к. я перезагружаюсь раз в 30-40 дней, то это не очень важно. Плюс на build сервере есть результаты
сборки всех ревизий.
Z>>Я бы не назвал scons/waf особо популярным.
_>Ну да, с помощью них всего лишь строят такие незначительные проекты как Chrome, Samba, Blender, VMware, MongoDB, Node.js и т.д. )))
Я недавно баг в chromium исправлял, там генератор проектов gyp, а саму сборку осуществляет ninja (там когда-то была scons,
но из-за тормознутости от нее отказались).
Еще с Blender знаком, нельзя сказать, что там только scons, их там две: cmake и scons.
С остальными проектами не работал, но вы уверены, что там именно эти системы сборки используются?
Z>>А make или qmake они хотят реализовать в следующей версии, но пока не решили кто из них популярнее.
_>Очевидно, что make намного популярнее, т.к. qmake — это по сути игрушка только для пользователей одного специфического фреймворка. Однако не удивлюсь, если они выберут именно qmake, т.к. там вроде тоже какой-то генератор...
Видел несколько проектов, в которых Qt нет, а qmake используется, т.к. по мнению использующих это простая и быстрая система.
Здравствуйте, Zhendos, Вы писали:
Z>А откуда цифры? Скажем на stackoverflow я время от времени вижу вопросы про cmake, намного реже про qmake, Z>и совсем не видел про python based.
На самом деле, если брать по существующим проектам, то насколько я помню с большим отрывом идут autotools и просто make. Просто на мой взгляд это полностью устаревшие системы и начинать сейчас новые проекты на них не особо разумно (хотя многие всё равно это делают, видимо лень изучать современные инструменты). CMake — это скорее самое популярное из современных средств. )
Z>Не совсем понял, имеется ввиду, если я перезагружусь, то придется все перестраивать? Z>Т.к. я перезагружаюсь раз в 30-40 дней, то это не очень важно. Плюс на build сервере есть результаты Z>сборки всех ревизий.
Я имею в виду, что если я сейчас зайду в архив свои проектов, то в большинстве случаев могу просто запустить результат работы (exe обычно) прямо из папки проекта, где он хранится с момента последнего построения. А в случае построений только в оперативной памяти, придётся строить проект заново (а это иногда занимает десятки минут).
Z>Я недавно баг в chromium исправлял, там генератор проектов gyp, а саму сборку осуществляет ninja (там когда-то была scons, Z>но из-за тормознутости от нее отказались).
Ну я как бы не отслеживаю ситуацию, помню что оно там было. И scons действительно тормознутый из-за одного просчёта в архитектуре. Именно из-за него и появился waf (наследник scons, но работающий очень быстро).
Но в контексте нашей дискуссии это всё абсолютно не принципиально, т.к. мы видим, что здесь проект перешёл с scons не на cmake, а на gyp. Т.е. на опять же неподдерживамое в данный момент в CLion.
Z>С остальными проектами не работал, но вы уверены, что там именно эти системы сборки используются?
В какой-то момент времени) Ну и естественно это не полный список, а просто то, что пришло в голову. ))) Подробнее можно глянуть где-нибудь здесь http://www.scons.org/wiki/SconsProjects и здесь https://code.google.com/p/waf/wiki/ProjectsUsingWaf.
Z>Видел несколько проектов, в которых Qt нет, а qmake используется, т.к. по мнению использующих это простая и быстрая система.
Вообще говоря qmake (так же как скажем cmake, gyp, autotools) являются не совсем системами сборки, а скорее генераторами конфигурационных файлов для элементарных нативных систем. Лично мне не особо нравится данный подход с лишним звеном.
Здравствуйте, alex_public, Вы писали:
_>Собственно поэтому IDE поддерживающая одну систему сборки и выглядит странно.
Ну справедливости ради — вижуал студия вообще "ни одной системы" не поддерживает (кроме собственной). И всякие генераторы типа цмейка должны под неё "постраиваться".
Или даже QtCreator — там ведь поддерживается только своя и cmake, вроде.
_>Image: clion.png и где здесь сеть?
Да, похоже, что на винде не предусмотрена такая возможность. Заведите тикет здесь, пожалуйста: https://youtrack.jetbrains.com/issues/IDEA
_>Ещё раз повторю свою точку зрения (и уверен, что её придерживается большинство): я не собираюсь переходить на другую (причём в моём случае более слабую) систему сборки ради чуть лучшего редактора.
Это Ваше право, безусловно)
_>Почему нельзя было просто сделать возможность запуска произвольной команды для построения — это для меня загадка. Такое есть вообще везде, даже не в ide, в обычных редакторах.
Потому что IDE (в отличие от обычных текстовых редакторов) использует информацию, которая передается в системе сборки для анализа, резолва и пр. кода. То есть IDE сейчас умеет "понимать", что же за опции указаны в CMake, какие файлы включены в проект и пр. Так что тут — либо своя система такая, либо уже имеющаяся.
_>Даже если действительно нужно создавать все эти каталоги сразу, то не вижу никаких проблем делать это в каталоге проекта. Всё равно же вы мусорите туда (.idea).
.idea хранит все, что специфично для проекта — настройки code style, инспекций, и тд — это в целом можно пошарить вместе с проектом в команде, поэтому имеет смысл держать рядом с проектом.
Здравствуйте, DarkEld3r, Вы писали:
DE>Ну справедливости ради — вижуал студия вообще "ни одной системы" не поддерживает (кроме собственной). И всякие генераторы типа цмейка должны под неё "постраиваться".
DE>Или даже QtCreator — там ведь поддерживается только своя и cmake, вроде.
Не, в QtCreator можно добавить произвольное число кастомных (просто указывается команда на исполнение, параметры, каталог) шагов построения. И при этом можно удалить стандартный шаг.
В VS немного по другому, но тоже без проблем делаются кастомные построения. Причём в итоге там даже более гибко можно сделать).
Что касается CLion, то в данный момент ближайшим аналогом этих вариантов является замена "add_executable" на "add_custom_target" в CMakeLists.txt. Я попробовал... Ну для начала наша команда построения будет запускаться в том странном сгенерированном каталоге, а не в папке проекта, так что уже возникают сложности с путями (где брать исходники?). Но предположим, что мы как-то решили эту проблему и получили подобное решение через задницу (там получится чудная цепочка процессов CLion->make->cmake->cmd->python(waf)->g++). Но почему-то при таком раскладе перестал работать анализатор кода (если вернуть add_executable, то снова работает), ради которого это всё собственно и затевалось. В общем хрень у них вышла. И всё из-за того, что у кого-то в голове спутались две разные вещи: система сборки и система проектов ide.
Здравствуйте, anastasiak2512, Вы писали:
_>>Почему нельзя было просто сделать возможность запуска произвольной команды для построения — это для меня загадка. Такое есть вообще везде, даже не в ide, в обычных редакторах. A>Потому что IDE (в отличие от обычных текстовых редакторов) использует информацию, которая передается в системе сборки для анализа, резолва и пр. кода. То есть IDE сейчас умеет "понимать", что же за опции указаны в CMake, какие файлы включены в проект и пр. Так что тут — либо своя система такая, либо уже имеющаяся.
У вас какая-то путаница в голове: слиты в единое целое система сборки (которая в принципе должна быть независима от ide) и система проектов ide (хранящая настройки проекта нужные для ide).
Никто не предлагает писать свою систему сборки. А вот написать свою систему проектов (т.е. по сути просто сохранение/востановление пары опций) явно не помешало бы. При таком раскладе не надо было бы страдать парсингом конфига для сборки и соответственно можно было бы одним простейшим движением (возможностью запуска произвольной команды при построение) поддержать сразу все существующие системы сборки.
Более того, у вас такая система проектов похоже уже есть прямо сейчас (судя по тексту ниже), только она не имеет такого официального названия (ну да, "специфичные для проекта code style" — это конечно совсем другое... ). Так что я вдвойне не понимаю это ваше странное решение.
_>>Даже если действительно нужно создавать все эти каталоги сразу, то не вижу никаких проблем делать это в каталоге проекта. Всё равно же вы мусорите туда (.idea). A>.idea хранит все, что специфично для проекта — настройки code style, инспекций, и тд — это в целом можно пошарить вместе с проектом в команде, поэтому имеет смысл держать рядом с проектом.
И что мешает хранить в этой папке список папок с заголовочным файлами и возможно опции препроцессора (большего же для анализатора кода и не требуется)? Оно разве не "специфичное для проекта"? ) Или очень сложно добавить ещё один маленький диалог с настройкой этих опций? )
Здравствуйте, alex_public, Вы писали:
_>4. А где локализация? ) Понятно что для программистов это вопрос совершенно не принципиальный. Но с учётом того, что даже мелкие бесплатные редакторы (типа Notepad++) имеют локазализацию (причём работающую по умолчанию), а во всех сравнимых конкурентах (Netbeans, Eclipse, Visual Studio) это уже давно работает, то несколько удивляет. Тем более, что уж для русской версии переводчиков точно не пришлось бы нанимать. )))
Да я половину слов не пойму в локализованной IDE, не говоря уж о том, как гуглить ошибки на русском — вместо наиболее вероятного SO или MSDN по первой же ссылке, попадаешь на всякие говнофорумы, где про эту ошибку только вопрос в стиле:"памагите у миня ни работает" и никаких ответов.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, Ops, Вы писали:
Ops>Да я половину слов не пойму в локализованной IDE, не говоря уж о том, как гуглить ошибки на русском — вместо наиболее вероятного SO или MSDN по первой же ссылке, попадаешь на всякие говнофорумы, где про эту ошибку только вопрос в стиле:"памагите у миня ни работает" и никаких ответов.
Хех, теперь осталось только понять, а что же ты собственно забыл в данный момент на подобном "говнофоруме"?
Здравствуйте, alex_public, Вы писали:
Ops>>Да я половину слов не пойму в локализованной IDE, не говоря уж о том, как гуглить ошибки на русском — вместо наиболее вероятного SO или MSDN по первой же ссылке, попадаешь на всякие говнофорумы, где про эту ошибку только вопрос в стиле:"памагите у миня ни работает" и никаких ответов.
_>Хех, теперь осталось только понять, а что же ты собственно забыл в данный момент на подобном "говнофоруме"?
Откуда вдруг такой вывод, что он "подобный"? Правда, попробуй погуглить ошибки студии на русском, поймешь, о чем я.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, alex_public, Вы писали:
_>Я к тому, что мы сейчас находимся на русскоязычном форуме. Пишем по русски. И вроде как вполне не плохо друг друга понимаем... )
И как это может мне помочь понять, что имели в виду переводчики, когда переводили интерфейс, если я только англоязычные всю жизнь видел? Там же половина слов либо переводится неоднозначно, либо не имеет прямых русских аналогов, и сиди-думай, что бы это значило, или ищи полчаса нужный пункт меню.
_>Да, кстати, а зачем гуглить ошибки компилятора? Там же собственно всё нужное и так написано (и не важно на каком языке) в самой ошибке.
Иногда недостаточно, хочется узнать не что за ошибка, а как лечить применительно к конкретной библиотеке.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
и где здесь сеть?
— конечно тоже ерунда, по сравнению со стандартным окном винды, но во всяком случае все необходимые элементы имеются.
это ужас. Эти дебилы локализовали сообщения компилятора и линкера. 
