Ну что же, поставил я данный продукт, поигрался и готов поделиться впечатлениями. Во-первых сразу же скажу, что у меня были связаны с ним большие ожидания, т.к. в области полноценных C++ IDE выбор очень небольшой (собственно только 3 продукта и могут бороться за первое место) и у каждого варианта есть свои недостатки. А судя по уровню IDEA можно было надеяться на прорыв именно в самой проблемой области (анализатор кода и всё из него следующее). Так вот если кратко, то CLion в общем то оправдал надежды в этой области, но совершенно неожиданно показал дикие (настолько, что для нас этот продукт сейчас не пригоден к использованию) провалы в других областях, вроде как тривиальных.
А теперь по порядку. И начать я хочу с набора вроде как неважных мелочей, чтобы потом не отвлекаться на них при обсуждение принципиальных вещей. И так мелкие огрехи:
1. Сразу бросилось в глаза, что CLion не сообщает Windows о том, что он умеет сам нормально работать с нестандартным DPI. В итоге винда его масштабирует как картинку — получаем размытость, что очевидно неприемлемо для IDE. Очень странно видеть такое у вроде как солидного продукта, в то время как даже мелкие бесплатные утилитки работают корректно. Более того, если для 32-ух битного приложения Windows позволяет указать опцию "не масштабировать" в свойствах exe файла в Проводнике, то для 64-ёх битного кода эта возможность заблокирована (кстати, кто-нибудь знает обоснование этого странного поступка MS?) и надо идти добавлять специальную строку в специальное место реестра (про которое далеко не все знают). Ну т.е. я проблему преодолел своими силами, но в целом дико видеть такое в солидном продукте.
2. Захотелось открыть файл и сразу поразился диалогу для этого. Он не просто совсем не стандартный, но похоже что и ещё не умеет видеть сеть (или я не увидел где это включается?).
3. Про неудобные полосы прокрутки (в которые ещё фиг попадёшь мышкой) тут уже вроде писали. Впрочем иконки на тулбаре тоже крайне мелкие, но тут хотя бы только размера, а не форма.
4. А где локализация? ) Понятно что для программистов это вопрос совершенно не принципиальный. Но с учётом того, что даже мелкие бесплатные редакторы (типа Notepad++) имеют локазализацию (причём работающую по умолчанию), а во всех сравнимых конкурентах (Netbeans, Eclipse, Visual Studio) это уже давно работает, то несколько удивляет. Тем более, что уж для русской версии переводчиков точно не пришлось бы нанимать. )))
Кстати, замечу, что все вышеуказанные проблемы явно не связаны со спецификой C++. Интересно, а в других продуктах компании наблюдаются эти же проблемы или нет? Т.е. это предрелизные проблемы или вообще характерное для них? Я сам не в курсе, т.к. для нас у них раньше не было подходящих продуктов.
Переходим к основному. Первым делом нас конечно встречает редактор. Ну а точнее его настройки, т.к. я сразу полез в них. Ну что я могу сказать... Пожалуй это лучшее, что я видел среди всех IDE. Причём там нет какой-то одной уникальной киллер-фичи, а просто по совокупности разных продуманных мелочей редактор выглядит заметно удобнее всех своих конкурентов. Не буду расписывать тут подробности (авторы сами это легко сделают в рекламных проспектах, в отличие от подробного описания проблем), но можно сказать что тут ожидания полностью оправдались.
Однако подобный редактор — это ничто без анализатора кода (самой проблемой частью для C++). Здесь у нас к сожалению нет какого-то гениального прорыва (типа парсинга 100% компилируемого кода, что кстати вполне возможно с помощью того-же clang'а, но пока слишком медленно), но и провала нет. По охвату кода ситуация наверное как у лидеров, но при этом ещё и быстродействие чуть лучше. В целом получается как минимум на уровне, если не лучший результат. В принципе тоже безусловный позитив, хотя тут ожидания были несколько большими. Ну и надо отметить, что памяти оно отжирает больше того же Netbeans'a (Eclipse'а и VS+VA сейчас под рукой нет, чтобы сравнить), но думаю что для компьютера разработчика это правильный размен.
Ну а дальше я перешёл к изучению системы проектов и тут уже пошёл ужас — её просто не оказалось в IDE вообще. Ну точнее она вся перенесена в сторонний инструмент (чужую систему сборки cmake). Как я понимаю, авторы решили поддержать правильную точку зрения (которой некоторые IDE не соответствуют), что нормальный проект должен уметь собираться без всяких IDE (т.е. не должен быть завязан на настройки проекта из IDE). Я эту точку зрения полностью поддерживаю, но она совершенно не означает то, что сделали в CLion. Для этого достаточно всего лишь обеспечить удобную поддержку запуска произвольных сторонних систем сборки и всё! Отказываться от настроек проекта внутри IDE для этого не требуется. Т.е. авторы CLion вроде как пошли по правильному пути, но зашли по нему куда-то слишком далеко. В принципе такое решение может быть успешным, но только при одном принципиальном условие: если до первого релиза CLion будет поддерживать все известные системы сборки (например мы сейчас используем waf). Надеюсь автор данной архитектуры чётко понимает это? Ну и я что-то сомневаюсь что такое удастся, причём не столько из-за их количества (основных всего штук 15, хотя это тоже не мелкое число), сколько из-за сложности "парсинга" конфигов в некоторых случаях и большого различия в принципах. В целом мне данное решение видится провалом. Можно было сделать гораздо проще — сборку отдать профессиональным инструментам (реализовав удобный их запуск), а настройки проекта оставить только для нужных IDE опций (типа include каталогов для анализатора кода и т.п.). Кстати, я бы ещё может с трудом понял подобное, если бы в папке проекта кроме CMakeLists.txt не появлялось вообще ничего. Однако там появляется целая новая папка с кучей мусора (и почему-то именем ".idea", а не ".clion). Почему нельзя было разместить в ней нужные анализатору кода настройки, а не заниматься сексом с CMakeLists.txt для меня загадка.
Но ещё больше чудес открылось, когда я перешёл к сборке... И тут дело совсем не в её архитектуре. Ну да, cmake, не лучшая система сборки, но и далеко не худшая. Ну да, зашита намертво и поддерживается только она одна. Но это вроде как только пока и обещают изменить к релизу. Всё дело в том, как тут cmake используется! Оно зачем-то создаёт папки (да, не одну, а сразу 5: default, Release, Debug, RelWithDebInfo, MinSizeRel — зачем???) для построения cmake'ом не в каталоге проекта, а где-то в домашнем каталоге пользователя (типа ~\.clion10\system\cmake\generated\7c448f19\7c448f19\)! Мне вот интересно, а "гений", придумавший это решение, вообще понимает, что:
— это может приводить к потери быстродействия (диски с проектами и домашним каталогом могут быть не просто с разной скоростью, а вообще расположены в разных точках планеты)
— это может являться существенной дырой в безопасности (к примеру у нас важные проекты живут на криптодисках, а домашние каталоги пользователей со всяким повседневным хламом естественно без всякой защиты)
— банально неудобно доставить оттуда exe в итоге.
Причём главное что я не понимаю смысла этого гениального решения — какой вообще может быть аргумент в пользу подобного извращения? Да, а в какой-нибудь IDE такое вообще встречалось? Я вот что-то не припомню.
Кстати, я попробовал прикрутить нормальное построение (другим инструментом и в каталоге проекта) через External Tools. Кривизна конечно, но для предрелиза сойдёт. Вроде как всё нормально заработало. Но тут выяснилось, что без корректного CMakeLists.txt не работает анализатор кода (а без него уже смысла в IDE нет). Ну хорошо, поставил корректный файл, но убрал шаг build (из run/debug) и не нажимал его руками. И что вы думаете? Оно всё равно тут же сгенерировало все эти 5 папок с полным содержимым (да, кстати, забыл добавить, что там ещё зачем-то лежат сгенерированные проекты для codeblock — а они то зачем???) в домашнем каталоге... Даже не знаю что сказать на это всё.
Ну и напоследок об остальных компонентах, которые не произвели какого-то яркого (позитивного или негативного) впечатления.
Отладчик — ничего особо интересного, но нормально работает.
Всяческие интеграции — благодаря системе плагинов думаю что в будущем может быть идеально. Ну и даже уже сейчас, до релиза, имеется набор большинства важных вещей.
Если подвести итог с оценками, то по моим ощущениям это выглядело бы так:
— Интерфейс: 3-4.
— Редактор: 5.
— Анализатор кода: 4-5 (выше 4 только за счёт скорости).
— Проекты: 3.
— Сборка: 1.
— Отладчик: 4.
— Интеграции: 4-5 (4 сейчас, а 5 думаю быстро станет после релиза).
Для сравнения покажу такую же свою оценку Netbeans'a (на мой взгляд самого оптимального инструмента сейчас, хотя Eclipse не далеко от него):
— Интерфейс: 4-5.
— Редактор: 4.
— Анализатор кода: 4.
— Проекты: 4.
— Сборка: 4.
— Отладчик: 4.
— Интеграции: 5.
К сожалению для нас из всего этого следует, что переход на новую более удобную IDE похоже не состоится...
P.S. Тут вроде как на форуме присутствовали люди из JB. Надеюсь они передадут это отзыв по назначению. Я всё же его писал не ради самой критики, а с тайной надеждой на чудо в будущем... )))
Здравствуйте, Cyberax, Вы писали:
C>Они используют CMake напрямую в качестве проектных файлов.
И толку? Например у нас проект – адская смесь CMake, Make и bash скриптов. Лично мне в обязательном порядке от любой IDE нужна возможность подгрузить все дерево исходников "как есть", а там уж разберемся.
Здравствуйте, alex_public, Вы писали:
_>Да? ) Т.е. на форуме ты тут пишешь "я сделал file open и потом запустил debug"? ) Или может всё же по другому пишешь? )
Есть и другие примеры. Например, знаешь, что такое "иерархия вызовов"? Это так call stack обозвали. Или вот "панель элементов" — toolbox. Попробуй угадай.
А если в настройки проекта залезть, то сидишь и думаешь, что бы эта настройка значила, inline — оно и в индии inline, накрайняк инлайн, а оказывается "подставляемая". Тьфу.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Get your MinGW-w64 compiler installed somewhere.
Create a file with the path [MinGW-w64 dir]/include/_mingw.h and the content shown below.
Point CLion to your [MinGW-w64 dir] and watch how CLion recognizes your MinGW setup.
_mingw.h
Disclaimer: CLion is still in an Early Access Program and may change any day. This trick worked for me, but there’s still a chance that it might not work for you.
Я сам еще не пробовал, т.к. нет Windows под рукой.
Здравствуйте, 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.
Здравствуйте, denisko, Вы писали:
KP>>Ну я бы сказал это Alfa, если сравнивать с CDT для Eclipse. Нашу кодовую базу не осилило D>т.е cdt лучше? спасибо,нет.
Ну как сказать лучше/хуже... CDT осилил кодовую базу, а CLion – нет. Как их можно сравнивать, если один работает, а второй нет?
Здравствуйте, Cyberax, Вы писали:
C>Вышел первый preview для новой C++ IDE от JetBrains.
Увы потестить не удалось, так как данное поделие упорно отказалось опознать MinGW. Проблема известная:
Removing MinGW, MinGW/MSYS and CMake from PATH environment variable resolved the issue and all tools are detected automatically.
I had a similar issue, same effects, however it was due to me having the msysgit bin in my path. Removing it allowed detection of the MinGW compilers again.
Ну уж нет, спасибо.
Не знаю, как он там с кодом будет работать, но упоротый явовский гуй огорчает. Как человек год плотно работавший с Idea заявляю — юзабилистов гнать, гуй крайне неудобный, одни скроллеры в маковском стиле без стрелок чего стоят.
Здравствуйте, MTD, Вы писали:
MTD>Ну уж нет, спасибо.
Первый preview, однако.
MTD>Не знаю, как он там с кодом будет работать, но упоротый явовский гуй огорчает. Как человек год плотно работавший с Idea заявляю — юзабилистов гнать, гуй крайне неудобный, одни скроллеры в маковском стиле без стрелок чего стоят.
Вот не надо. Usability в IDEA лучше, чем во всех остальных редакторах. Нафиг скроллеры со стрелочками вообще нужны, когда есть клавиатура?
Здравствуйте, Zhendos, Вы писали:
Z>Но интерфейс действительно какие-то криворукие делали. Z>Правда неясно кто конкретно, oracle или jetbrains.
В IDEA лучший интерфейс из всех IDE.
Z>но поле для редактирования размера шрифта в clion read-only,
Умм, там перед полем чекбоксик "Override default font size". После него всё работает.
C>>Да, прокрутка без подгонки курсора к краю — ctrl+стрелки или обычные pgup/pgdown.
MTD>Сразу видно настоящих логов ты не видал, руки отсохнут ctrl+стрелки делать.
Здравствуйте, kaa.python, Вы писали:
KP>Здравствуйте, Cyberax, Вы писали:
C>>Вышел первый preview для новой C++ IDE от JetBrains.
KP>Ну я бы сказал это Alfa, если сравнивать с CDT для Eclipse. Нашу кодовую базу не осилило
т.е cdt лучше? спасибо,нет.
Здравствуйте, kaa.python, Вы писали:
KP>Здравствуйте, denisko, Вы писали:
KP>>>Ну я бы сказал это Alfa, если сравнивать с CDT для Eclipse. Нашу кодовую базу не осилило D>>т.е cdt лучше? спасибо,нет.
KP>Ну как сказать лучше/хуже... CDT осилил кодовую базу, а CLion – нет. Как их можно сравнивать
Визуально. Если один не вызывает желания крикнуть "..... ... ... .... ", а второй вызывает, то превый лучше. Код он завтра осилит, а второй, как был черезколеннорукожопносделаннымэклипсоуежищем так и останется.
Здравствуйте, kaa.python, Вы писали:
KP>Ну я бы сказал это Alfa, если сравнивать с CDT для Eclipse. Нашу кодовую базу не осилило
А на чём упало?
Можешь минимальный пример сделать?
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>А на чём упало? WH>Можешь минимальный пример сделать?
Не, оно не упало. Я создал проект указав ему в качестве корня директорию с нашими сорцами и оно просто не догнало где какие лежат определения. В итоге 90-95% типов не видно. Переходы работают в рамках одного файла, в лучшем случае по файлам что рядом валяются. Может я что-то не так сделал, конечно
Здравствуйте, WolfHound, Вы писали:
KP>>Ну я бы сказал это Alfa, если сравнивать с CDT для Eclipse. Нашу кодовую базу не осилило WH>А на чём упало? WH>Можешь минимальный пример сделать?
err(errWarn) подсвечивается как ошибка.
struct err : public std::stringstream
{
err(code_e code) : code_(code) {}
~err()
{
//Yes, we're throwing from a destructorif (code_!=errNone)
{
boost::throw_exception(es3_exception(result_code_t(code_, str())));
}
}
private:
code_e code_;
};
...
if (something)
err(errWarn) << "curl error: " << err_buf_;
Вообще, с исключениями много проблем. Ещё почему-то не распарсился libcurl.h — все вызовы curl_easy_reset подсвечены.
Здравствуйте, kaa.python, Вы писали:
KP>Не, оно не упало. Я создал проект указав ему в качестве корня директорию с нашими сорцами и оно просто не догнало где какие лежат определения. В итоге 90-95% типов не видно. Переходы работают в рамках одного файла, в лучшем случае по файлам что рядом валяются. Может я что-то не так сделал, конечно
Завтра отправлю в эту тему парней, которые С++ом занимаются.
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
А что она хочет в качестве "MinGW Home"?
Даю ей папку с qt-шным mingw ("C:\Qt\Qt5.3.1\Tools\mingw482_32" или "C:\Qt\Qt5.3.1\Tools\mingw482_32\bin")
Пишет что mingw not found.
в переменных окружения принципиально ничего не прописываю, ибо у меня этих mingw 3 или 4 штуки для разных целей...
Еще непонятно есть ли импорт из форматов Visual Studio vc(x)proj, sln, из qt-шных pro, из всяческих других форматов различных IDE, просто из файловой системы с исходниками...
ИМХО любая новая среда разработки должна в первую очередь позаботиться об удобстве перехода с существующих IDE.
Здравствуйте, x-code, Вы писали:
XC>Еще непонятно есть ли импорт из форматов Visual Studio vc(x)proj, sln, из qt-шных pro, из всяческих других форматов различных IDE, просто из файловой системы с исходниками... XC>ИМХО любая новая среда разработки должна в первую очередь позаботиться об удобстве перехода с существующих IDE.
Они используют CMake напрямую в качестве проектных файлов.
Здравствуйте, kaa.python, Вы писали:
C>>Они используют CMake напрямую в качестве проектных файлов. KP>И толку? Например у нас проект – адская смесь CMake, Make и bash скриптов. Лично мне в обязательном порядке от любой IDE нужна возможность подгрузить все дерево исходников "как есть", а там уж разберемся.
У меня в дереве есть левые исходники, CLion их показывает в дереве файлов затемнёнными, но при этом подгружает и понимает.
Очень надо, развесистые логи смотреть крайне затруднительно.
C>Usability в IDEA лучше, чем во всех остальных редакторах.
Местами да, местами нет. С шорткатами нормально, явовский гуй убог и жалок.
C>Нафиг скроллеры со стрелочками вообще нужны, когда есть клавиатура?
Во-первых, надо шелкнуть в окошко, во-вторых курсорчик надо подогнать к краю, а если надо вверх-вниз или влево-вправо вообще запаришься его туда сюда гонять.
Здравствуйте, MTD, Вы писали:
C>>Вот не надо. MTD>Очень надо, развесистые логи смотреть крайне затруднительно.
Мышкой нажимать на стрелочки для просмотра развесистых логов? Да вы, батенька, гурман.
C>>Usability в IDEA лучше, чем во всех остальных редакторах. MTD>Местами да, местами нет. С шорткатами нормально, явовский гуй убог и жалок.
А что с ним конкретно не так? Дерево файлов есть, табы нормальные, текст редактируется.
C>>Нафиг скроллеры со стрелочками вообще нужны, когда есть клавиатура? MTD>Во-первых, надо шелкнуть в окошко, во-вторых курсорчик надо подогнать к краю, а если надо вверх-вниз или влево-вправо вообще запаришься его туда сюда гонять.
Щёлкнуть??? Это же надо крысу в руки брать! Да, прокрутка без подгонки курсора к краю — ctrl+стрелки или обычные pgup/pgdown.
Здравствуйте, Cyberax, Вы писали:
MTD>>Очень надо, развесистые логи смотреть крайне затруднительно. C>Мышкой нажимать на стрелочки для просмотра развесистых логов? Да вы, батенька, гурман.
А как надо? В любом случае гуй должен быть удобным для всех, чем стрелки у скроллера мешали?
C>Дерево файлов есть
Оно не нативное, кроме того оно урезано по самое не балуй, например, я не могу при добавлении ресурсов сделать превью файлов.
C>табы нормальные
Организация табов вообще дебильная — при открытии новых файлов, табы меняют местоположение, поэтому нельзя вернуться к старому файлу, не сделав умственное усилие. Да и просто нет списка открытых файлов, как например в Qt Creator, что иногда очень удобно.
C>текст редактируется.
Хвала богам.
C>Да, прокрутка без подгонки курсора к краю — ctrl+стрелки или обычные pgup/pgdown.
Сразу видно настоящих логов ты не видал, руки отсохнут ctrl+стрелки делать.
Здравствуйте, MTD, Вы писали:
MTD>>>Очень надо, развесистые логи смотреть крайне затруднительно. C>>Мышкой нажимать на стрелочки для просмотра развесистых логов? Да вы, батенька, гурман. MTD>А как надо? В любом случае гуй должен быть удобным для всех, чем стрелки у скроллера мешали?
Горизонтальное место занимают.
C>>Дерево файлов есть MTD>Оно не нативное, кроме того оно урезано по самое не балуй, например, я не могу при добавлении ресурсов сделать превью файлов.
А нафиг нативное?
C>>табы нормальные MTD>Организация табов вообще дебильная — при открытии новых файлов, табы меняют местоположение, поэтому нельзя вернуться к старому файлу, не сделав умственное усилие.
Можно поменять в опициях Editor -> Editor Tabs.
MTD>Да и просто нет списка открытых файлов, как например в Qt Creator, что иногда очень удобно.
"Список открытых файлов" — это какой-то пережиток прошлого.
C>>Да, прокрутка без подгонки курсора к краю — ctrl+стрелки или обычные pgup/pgdown. MTD>Сразу видно настоящих логов ты не видал, руки отсохнут ctrl+стрелки делать.
Лучше кликать на "стрелку вниз" мышкой? В IDEA есть overview для файлов, кстати.
Здравствуйте, Cyberax, Вы писали:
C>Вот не надо. Usability в IDEA лучше, чем во всех остальных редакторах. Нафиг скроллеры со стрелочками вообще нужны, когда есть клавиатура?
Со скроллерами одна проблема — с планшета скроллить неудобно. Пальцем хрен попадешь, а ожидаемый жест работает как выделение.
Здравствуйте, Cyberax, Вы писали:
C>Горизонтальное место занимают.
Ага аж процентов 5 будет — впечатляющая экономия на спичках. Думаю все гораздо проще, пустоголовые дизайнеры увидели, что на маке так и подумали, что это круто.
MTD>>Оно не нативное, кроме того оно урезано по самое не балуй, например, я не могу при добавлении ресурсов сделать превью файлов. C>А нафиг нативное?
Во-первых, привычней, во-вторых оно функциональней, например, я могу при добавлении ресурсов посмотреть превью файлов.
C>>>табы нормальные MTD>>Организация табов вообще дебильная — при открытии новых файлов, табы меняют местоположение, поэтому нельзя вернуться к старому файлу, не сделав умственное усилие. C>Можно поменять в опициях Editor -> Editor Tabs.
Нельзя, там такого нет.
MTD>>Да и просто нет списка открытых файлов, как например в Qt Creator, что иногда очень удобно. C>"Список открытых файлов" — это какой-то пережиток прошлого.
Все твои аргументы — я этим не пользуюсь, значит не надо. Слабовато.
C>Лучше кликать на "стрелку вниз" мышкой?
Когда как. В любом случае хорошие инструменты позволяют достигать целей разными способами — кому как удобней.
Здравствуйте, elmal, Вы писали:
C>>Вот не надо. Usability в IDEA лучше, чем во всех остальных редакторах. Нафиг скроллеры со стрелочками вообще нужны, когда есть клавиатура? E>Со скроллерами одна проблема — с планшета скроллить неудобно. Пальцем хрен попадешь, а ожидаемый жест работает как выделение.
IDEA на планшете неюзабельна в принципе.
Здравствуйте, x-code, Вы писали:
XC>Здравствуйте, Cyberax, Вы писали:
XC>А что она хочет в качестве "MinGW Home"? XC>Даю ей папку с qt-шным mingw ("C:\Qt\Qt5.3.1\Tools\mingw482_32" или "C:\Qt\Qt5.3.1\Tools\mingw482_32\bin") XC>Пишет что mingw not found. XC>в переменных окружения принципиально ничего не прописываю, ибо у меня этих mingw 3 или 4 штуки для разных целей...
ИМХО, хочет не "оно", а cmake. А они всего лишь используют то,
что нашел cmake. cmake нужно либо чтобы путь был в PATH,
либо с помощью "CC" и "CXX" указать конкретные бинарники.
А в windows разве нельзя переменные окружения выставить для "подветки" процессов?
типа в cmd указать нужные переменные, а потом оттуда запустить clion?
Здравствуйте, x-code, Вы писали:
XC>Здравствуйте, Cyberax, Вы писали:
XC>Еще непонятно есть ли импорт из форматов Visual Studio vc(x)proj, sln, из qt-шных pro, из всяческих других форматов различных IDE, просто из файловой системы с исходниками... XC>ИМХО любая новая среда разработки должна в первую очередь позаботиться об удобстве перехода с существующих IDE.
В первой версии они решили сделать поддержку cmake,
сейчас по результатам голосования они решают что делать дальше
qmake или makefile
но поле для редактирования размера шрифта в clion read-only,
а вот это уже баг jetbrains.
В общем запустить пару раз и полюбоваться на тормозящую
хреновину с малюсенькими буквами можно,
но вот работать в ней
Здравствуйте, MTD, Вы писали:
MTD>Здравствуйте, Zhendos, Вы писали:
Z>>ИМХО, хочет не "оно", а cmake.
MTD>Нет. У меня смаке все находит, а clion нет.
Z>>типа в cmd указать нужные переменные, а потом оттуда запустить clion?
MTD>Можно.
скорее всего тогда clion вырезает какие-то переменные окружения.
тогда должен помочь старый добрый трюк:
типа cmake.bat
PATH=
call_real_cmake %args%
(не помню как в синтаксисе батников обозначается все аргументы,
аналог $@ для /bin/sh)
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, Zhendos, Вы писали:
Z>>Но интерфейс действительно какие-то криворукие делали. Z>>Правда неясно кто конкретно, oracle или jetbrains. C>В IDEA лучший интерфейс из всех IDE.
Может быть в целом, но инструмент для реализации Desktop GUI они выбрали
явно не тот.
Z>>но поле для редактирования размера шрифта в clion read-only, C>Умм, там перед полем чекбоксик "Override default font size". После него всё работает.
Здравствуйте, Zhendos, Вы писали:
C>>В IDEA лучший интерфейс из всех IDE. Z>Может быть в целом, но инструмент для реализации Desktop GUI они выбрали Z>явно не тот.
Вариантов сильно лучше в 2000-м году не было.
Z>Правда некоторые надписи теперь друг на друга налезают.
Лучше всего зарепортить им баг. На Mac OS X у меня всё отлично, кстати.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, Zhendos, Вы писали:
C>>>В IDEA лучший интерфейс из всех IDE. Z>>Может быть в целом, но инструмент для реализации Desktop GUI они выбрали Z>>явно не тот. C>Вариантов сильно лучше в 2000-м году не было.
Z>>Правда некоторые надписи теперь друг на друга налезают. C>Лучше всего зарепортить им баг.
Дык он у них уже есть, они его полгода не чинят, я приводи ссылку в начале.
> На Mac OS X у меня всё отлично, кстати.
Это только на Windows и Linux, судя по багу. Т.к. в Mac OS X есть режим совместимости,
или как они его там называют, когда делают из четырех один пиксель.
Здравствуйте, Zhendos, Вы писали:
Z>>>Правда некоторые надписи теперь друг на друга налезают. C>>Лучше всего зарепортить им баг. Z>Дык он у них уже есть, они его полгода не чинят, я приводи ссылку в начале.
Интересно, у меня на Windows всё ОК.
>> На Mac OS X у меня всё отлично, кстати. Z>Это только на Windows и Linux, судя по багу. Т.к. в Mac OS X есть режим совместимости, Z>или как они его там называют, когда делают из четырех один пиксель.
Нет, IDEA работает в режиме HiDPI, без совместимости.
Здравствуйте, Zhendos, Вы писали:
Z>А он c++11 понимает? Когда последний раз Z>пробовал он мне чуть ли не половину 50k моего маленького проекта Z>красным обвел.
понимает. У него есть грабли на навороченном бусте, но std и простой буст (вроде shared_ptr, property_tree и т.п.) — полет нормальный.
Насчет красным обвел — ему надо как-то указать пути к инклюдам и предопределенные макросы. Или руками, или он берет стандартные, или может парсить выхлоп "gcc -E -P -v -dD"
Здравствуйте, Cyberax, Вы писали:
C>Вот не надо. Usability в IDEA лучше, чем во всех остальных редакторах. Нафиг скроллеры со стрелочками вообще нужны, когда есть клавиатура?
Пытаюсь привыкнуть (PyCharm). Пока идет плохо: запускается долго, рендеринг шрифтов плохой, предложение по улучшению кода левые, REPL кривоват. Пока не сдаюсь.
До этого пробовал Аптану — комфорт лучше, но баги с git-итеграцией достали.
я вот только одного не понял, чем QtCreator не устраивает в плане анализа кода? он с третьей версии использует clang для этого. этой фитчи я от него ждал несколько лет, и получил.
автодополнене так же основано на использовании clang, торможит очень слабо, в сравнении с этим же clion.
в общем-то, сейчас, QtCreator — мой герой
пачка бумаги А4 стОит 2000 р, в ней 500 листов. получается, лист обычной бумаги стОит дороже имперского рубля =)
Здравствуйте, niXman, Вы писали:
X>жуть как много букаф %)
Ну это как бы отзыв для разработчиков, в надежде что они прислушаются к доводам разума. )
X>я вот только одного не понял, чем QtCreator не устраивает в плане анализа кода? он с третьей версии использует clang для этого. этой фитчи я от него ждал несколько лет, и получил. X>автодополнене так же основано на использовании clang, торможит очень слабо, в сравнении с этим же clion.
Не пробовал ещё такой вариант. Действительно не тормозит? Я пробовал автодополнение clang'a в других местах (просто редакторах) и на серьёзных библиотеках (типа wxWidgets) тормозило просто дико.
X>в общем-то, сейчас, QtCreator — мой герой
Нууу как полноценная IDE то он конечно послабее главной троицы почти по всем пунктам. Это если не использовать Qt естественно. )
Здравствуйте, alex_public, Вы писали:
_>Не пробовал ещё такой вариант. Действительно не тормозит?
тормозит, но очень слабо. нужно пробовать, сравнивать.
у меня есть только опыт тестирования нетбинса в этой роли — вот он тормозит просто жутко %)
_>Нууу как полноценная IDE то он конечно послабее главной троицы почти по всем пунктам.
ну хз... мне так вообще его возможностей просто ооочень много =)
а что за "главная троица"? о чем речь?
_>Это если не использовать Qt естественно. )
не использую.
stl/boost/всякие_сторонние_либы...
пачка бумаги А4 стОит 2000 р, в ней 500 листов. получается, лист обычной бумаги стОит дороже имперского рубля =)
Здравствуйте, niXman, Вы писали:
X>тормозит, но очень слабо. нужно пробовать, сравнивать. X>у меня есть только опыт тестирования нетбинса в этой роли — вот он тормозит просто жутко %)
Какой-то анализатор на базе clang'а тормозит меньше чем Netbeans? Чудеса какие) Точно надо будет проверить. Может тогда и с некоторыми неудобствами среды можно будет смириться.
X>ну хз... мне так вообще его возможностей просто ооочень много =) X>а что за "главная троица"? о чем речь?
VisualStudio (с VisualAssist естественно), Eclipse, Netbeans. Все остальные не сравнимы с ними по возможностям. Речь естественно про C++ и про Windows (для линуха помнится ещё своё родное решение есть, тоже мощное).
_>>Это если не использовать Qt естественно. ) X>не использую. X>stl/boost/всякие_сторонние_либы...
Здравствуйте, alex_public, Вы писали:
_>Какой-то анализатор на базе clang'а тормозит меньше чем Netbeans? Чудеса какие)
IDE, использующих clang, я пробовал всего одну — QtCreator. и да, он вразы быстрее чем Netbeans. проверь.
(а Netbeans тоже использует clang?)
_>VisualStudio (с VisualAssist естественно), Eclipse
эти не пробовал, так что хз...
пачка бумаги А4 стОит 2000 р, в ней 500 листов. получается, лист обычной бумаги стОит дороже имперского рубля =)
Здравствуйте, alex_public, Вы писали:
_>Ну что же, поставил я данный продукт, поигрался и готов поделиться впечатлениями. Во-первых сразу же скажу, что у меня были связаны с ним большие ожидания, т.к. в области полноценных C++ IDE выбор очень небольшой (собственно только 3 продукта и могут бороться за первое место) и у каждого варианта есть свои недостатки. А судя по уровню IDEA можно было надеяться на прорыв именно в самой проблемой области (анализатор кода и всё из него следующее). Так вот если кратко, то CLion в общем то оправдал надежды в этой области, но совершенно неожиданно показал дикие (настолько, что для нас этот продукт сейчас не пригоден к использованию) провалы в других областях, вроде как тривиальных.
_>Ну а дальше я перешёл к изучению системы проектов и тут уже пошёл ужас — её просто не оказалось в IDE вообще. Ну точнее она вся перенесена в сторонний инструмент (чужую систему сборки cmake). _>Почему нельзя было разместить в ней нужные анализатору кода настройки, а не заниматься сексом с CMakeLists.txt для меня загадка.
По-моему овет очевиден. Для тех кто использует cmake настройки никуда вводить не надо. И по результатам
их исследований процент таких разработчиков (использующих cmake) достаточно велик.
_>Но ещё больше чудес открылось, когда я перешёл к сборке... И тут дело совсем не в её архитектуре. Ну да, cmake, не лучшая система сборки, но и далеко не худшая. Ну да, зашита намертво и поддерживается только она одна. Но это вроде как только пока и обещают изменить к релизу. Всё дело в том, как тут cmake используется! Оно зачем-то создаёт папки (да, не одну, а сразу 5: default, Release, Debug, RelWithDebInfo, MinSizeRel — зачем???) для построения cmake'ом не в каталоге проекта, а где-то в домашнем каталоге пользователя (типа ~\.clion10\system\cmake\generated\7c448f19\7c448f19\)!
временное решение symlink ".clion10/system" туда, куда ты хочешь,
а так есть http://youtrack.jetbrains.com/issue/CPP-96 голосуйте
_>Кстати, я попробовал прикрутить нормальное построение (другим инструментом и в каталоге проекта) через External Tools. Кривизна конечно, но для предрелиза сойдёт. Вроде как всё нормально заработало. Но тут выяснилось, что без корректного CMakeLists.txt не работает анализатор кода (а без него уже смысла в IDE нет). Ну хорошо, поставил корректный файл, но убрал шаг build (из run/debug) и не нажимал его руками. И что вы думаете? Оно всё равно тут же сгенерировало все эти 5 папок с полным содержимым
_>(да, кстати, забыл добавить, что там ещё зачем-то лежат сгенерированные проекты для codeblock — а они то зачем???) в домашнем каталоге... Даже не знаю что сказать на это всё.
Это способ извлечь информацию о структуре проекта из cmake, проектный генератор codeblocks работает поверх генераторов make/ninja и дает xml с информацией о проекте.
Здравствуйте, Zhendos, Вы писали:
Z>По-моему овет очевиден. Для тех кто использует cmake настройки никуда вводить не надо.
Так я же как раз написал там, что единственный вариант, когда эта стратегия окажется выигрышной, это если они сделают к первому релизу поддержку всех известных (ну скажем 15 топовых) систем построения. Иначе это провал, т.к. вряд ли кто будет менять свою систему построения на чужую неудобную ради чуть более удобного редактора.
Z>И по результатам их исследований процент таких разработчиков (использующих cmake) достаточно велик.
В принципе он может быть даже больше всех остальных систем, по одиночке. Но фокус в том, что их не две на рынке, а намного больше. Так что даже если cmake вообще лидер, то при этом процент от общего числа использований у него всё равно намного меньше 50... Т.е. получаем, что большую часть потенциальных клиентов они посылают.
Z>временное решение symlink ".clion10/system" туда, куда ты хочешь,
Не, так не пойдёт, т.к. я хочу банально в каталог проекта. Т.е. тогда надо делать ссылку каждого уродца типа "~\.clion10\system\cmake\generated\7c448f19\7c448f19\" в "Projects/XXX/Build". Ну теоретически это конечно решение, но опять же через задницу.
Z>а так есть http://youtrack.jetbrains.com/issue/CPP-96 голосуйте
Угу, т.е. теперь ещё бороться с этим... А хотя одна разумная причина для появления на свет этого извращения вообще есть? )
_>>(да, кстати, забыл добавить, что там ещё зачем-то лежат сгенерированные проекты для codeblock — а они то зачем???) в домашнем каталоге... Даже не знаю что сказать на это всё. Z>Это способ извлечь информацию о структуре проекта из cmake, проектный генератор codeblocks работает поверх генераторов make/ninja и дает xml с информацией о проекте.
Т.е. они даже не осилили парсинг cmake файла? А что они тогда думают делать с другими системами построения, которые не являются генераторами чего-то, а строят сами? Например весьма популярные scons/waf? Не говоря уже про банальные make/nmake.
Здравствуйте, alex_public, Вы писали:
_>Здравствуйте, Zhendos, Вы писали:
Z>>По-моему овет очевиден. Для тех кто использует cmake настройки никуда вводить не надо.
_>Так я же как раз написал там, что единственный вариант, когда эта стратегия окажется выигрышной, это если они сделают к первому релизу поддержку всех известных (ну скажем 15 топовых) систем построения. Иначе это провал, т.к. вряд ли кто будет менять свою систему построения на чужую неудобную ради чуть более удобного редактора.
Z>>И по результатам их исследований процент таких разработчиков (использующих cmake) достаточно велик.
_>В принципе он может быть даже больше всех остальных систем, по одиночке. Но фокус в том, что их не две на рынке, а намного больше. Так что даже если cmake вообще лидер, то при этом процент от общего числа использований у него всё равно намного меньше 50... Т.е. получаем, что большую часть потенциальных клиентов они посылают.
Не совсем понял вашу идею, допустим у cmake есть 50%, а остальное делят autotools, qmake и остальные.
Предположим также, что поддержка работы с каждой из них требует примерно одинаковых трудозатрат.
Очевидно же, что наиболее разумное вложение труздозатрат будет в порядке популярности этих систем (c учетом ограниченности "manpower").
Реализовали cmake, получили 50% от рынка, отбили текущие и будующие затраты, после этого выпускаем
следущую версию, с поддержкой следующей по популярности системы сборки.
Зачем им сразу 100%?
Кстати, следует учитывать, что на VS (вернее ее пользователей) они (CLion) не замахиваются,
т.к. есть Resharper C++.
Z>>временное решение symlink ".clion10/system" туда, куда ты хочешь,
Z>>а так есть http://youtrack.jetbrains.com/issue/CPP-96 голосуйте
_>Угу, т.е. теперь ещё бороться с этим... А хотя одна разумная причина для появления на свет этого извращения вообще есть? )
Мне скажем удобно, т.к. исходники я держу на SSD, а директорию для сборки в RAM, поэтому сделал symlink на /tmp, который у меня
в RAM смонтирован и вот уже clion настроен в соотвествии с моими предпочтениями. Возможно это довольно популярный сценария использования.
_>Т.е. они даже не осилили парсинг cmake файла? А что они тогда думают делать с другими системами построения, которые не являются генераторами чего-то, а строят сами? Например весьма популярные scons/waf? Не говоря уже про банальные make/nmake.
А зачем им по сути реализовывать еще один раз cmake внутри clion, если уже есть сам cmake?
Если они могут вызвать его(cmake) со специальными аргументами и получить все что нужно?
PS
Я бы не назвал scons/waf особо популярным. А make или qmake они хотят реализовать
в следующей версии, но пока не решили кто из них популярнее.
Здравствуйте, alex_public, Вы писали:
_>Ну что же, поставил я данный продукт, поигрался и готов поделиться впечатлениями. Во-первых сразу же скажу, что у меня были связаны с ним большие ожидания, т.к. в области полноценных C++ IDE выбор очень небольшой (собственно только 3 продукта и могут бороться за первое место) и у каждого варианта есть свои недостатки. А судя по уровню IDEA можно было надеяться на прорыв именно в самой проблемой области (анализатор кода и всё из него следующее). Так вот если кратко, то CLion в общем то оправдал надежды в этой области, но совершенно неожиданно показал дикие (настолько, что для нас этот продукт сейчас не пригоден к использованию) провалы в других областях, вроде как тривиальных.
_>А теперь по порядку. И начать я хочу с набора вроде как неважных мелочей, чтобы потом не отвлекаться на них при обсуждение принципиальных вещей. И так мелкие огрехи:
_>1. Сразу бросилось в глаза, что CLion не сообщает Windows о том, что он умеет сам нормально работать с нестандартным DPI. В итоге винда его масштабирует как картинку — получаем размытость, что очевидно неприемлемо для IDE. Очень странно видеть такое у вроде как солидного продукта, в то время как даже мелкие бесплатные утилитки работают корректно. Более того, если для 32-ух битного приложения Windows позволяет указать опцию "не масштабировать" в свойствах exe файла в Проводнике, то для 64-ёх битного кода эта возможность заблокирована (кстати, кто-нибудь знает обоснование этого странного поступка MS?) и надо идти добавлять специальную строку в специальное место реестра (про которое далеко не все знают). Ну т.е. я проблему преодолел своими силами, но в целом дико видеть такое в солидном продукте
Другие продукты jetbrains страдают от не 100% DPI. К браузере FireFox та же лажа — жирный шрифт в мыло. _>2. Захотелось открыть файл и сразу поразился диалогу для этого. Он не просто совсем не стандартный, но похоже что и ещё не умеет видеть сеть (или я не увидел где это включается?).
Да это болезнь — тут даже — при копировании папки появляются с заметной задержкой. _>3. Про неудобные полосы прокрутки (в которые ещё фиг попадёшь мышкой) тут уже вроде писали. Впрочем иконки на тулбаре тоже крайне мелкие, но тут хотя бы только размера, а не форма.
Хз так скролл очень редко использую. _>4. А где локализация? ) Понятно что для программистов это вопрос совершенно не принципиальный. Но с учётом того, что даже мелкие бесплатные редакторы (типа Notepad++) имеют локазализацию (причём работающую по умолчанию), а во всех сравнимых конкурентах (Netbeans, Eclipse, Visual Studio) это уже давно работает, то несколько удивляет. Тем более, что уж для русской версии переводчиков точно не пришлось бы нанимать. )))
За идею локализации IDE бить палкой надо.
тебе интуитивно понятны следующие слова?
Datei
geöffnet
Schließen
sparen
Einstellungen
Optionen
Здравствуйте, Zhendos, Вы писали:
Z>Не совсем понял вашу идею, допустим у cmake есть 50%, а остальное делят autotools, qmake и остальные.
В том то и дело, что там совсем не 50%. Об этом и была речь. Т.е. в данной области можно быть лидером, не набирая даже и 30% популярности. Собственно поэтому IDE поддерживающая одну систему сборки и выглядит странно.
Z>Мне скажем удобно, т.к. исходники я держу на SSD, а директорию для сборки в RAM, поэтому сделал symlink на /tmp, который у меня Z>в RAM смонтирован и вот уже clion настроен в соотвествии с моими предпочтениями. Возможно это довольно популярный сценария использования.
Нуу в принципе тоже вариант. А не смущает, что нельзя будет в будущем просто взять из проекта результат построения (придётся строить заново и потом копировать из /tmp)?
Z>А зачем им по сути реализовывать еще один раз cmake внутри clion, если уже есть сам cmake? Z>Если они могут вызвать его(cmake) со специальными аргументами и получить все что нужно?
Для cmake действительно не надо, но для других то так не получится. А я думал что они там некий обобщённый подход разработали для работы с чужими системами сборки (раз уж от своих настроек проекта отказались).
Z>Я бы не назвал scons/waf особо популярным.
Ну да, с помощью них всего лишь строят такие незначительные проекты как Chrome, Samba, Blender, VMware, MongoDB, Node.js и т.д. )))
Z>А make или qmake они хотят реализовать в следующей версии, но пока не решили кто из них популярнее.
Очевидно, что make намного популярнее, т.к. qmake — это по сути игрушка только для пользователей одного специфического фреймворка. Однако не удивлюсь, если они выберут именно qmake, т.к. там вроде тоже какой-то генератор...
Здравствуйте, vpchelko, Вы писали:
V>Другие продукты jetbrains страдают от не 100% DPI. К браузере FireFox та же лажа — жирный шрифт в мыло.
В firefox'е что-то не помню такого. Но даже если бы и было, то т.к. он 32-ух битный, то это отключалось бы в пару кликов мышкой любым пользователем.
V>За идею локализации IDE бить палкой надо.
Однако все серьёзные продукты в этой области имеют данную возможность. Более того, она обычно ещё и включена по умолчанию — похоже большая часть пользователей совсем не против.
V>тебе интуитивно понятны следующие слова? V>Datei V>geöffnet V>Schließen V>sparen V>Einstellungen V>Optionen
Ну я то этот язык не знаю, так что с чего бы они мне были знакомы? ) Не помню чтобы я натыкался на что-то непонятное в русских локализациях IDE.
Здравствуйте, niXman, Вы писали:
X>IDE, использующих clang, я пробовал всего одну — QtCreator. и да, он вразы быстрее чем Netbeans. проверь.
Попробовал поставить и пока немогу оценить качество автодополнения, т.к. он парсит мне исходники как для старого стандарта (ну т.е. я это подозреваю, т.к. скажем cout он видит правильно) и соответственно например класса thread не видно и т.д. Как подобное включается? Причём компилируется этот код нормально (я поставил set(CMAKE_CXX_FLAGS "-std=gnu++1y ${CMAKE_CXX_FLAGS}")). Кстати странно, этот код для IDE непонятен, но как ошибку не отмечает (другие обычно отмечают). А вот код в новом стандарте вида [v=v]{...} вполне себе пометила как ошибку (обычные лямбды при этом не подчёркнуты). Ну это и CLion помечает. А вот Netbeans нормально.
Да, кстати, а кодировку консоли там можно на обычную виндовую сменить? А то выводится непонятно что в ней. )))
X>(а Netbeans тоже использует clang?)
Здравствуйте, alex_public, Вы писали:
_>В firefox'е что-то не помню такого. Но даже если бы и было, то т.к. он 32-ух битный, то это отключалось бы в пару кликов мышкой любым пользователем.
Я не пользуюсь нестандартным DPI — просто проверил, паршиво шрифты рисует. Да понятно что можно все настроить, но по умолчанию бяка.
_>Однако все серьезные продукты в этой области имеют данную возможность. Более того, она обычно ещё и включена по умолчанию — похоже большая часть пользователей совсем не против.
Пользователи — это кто какие? Может кому-то надо... Программисту с опытом это не нужно — будет мешать.
И потом сиди ищи — что-там они тебе налоказиловали, когда в настройках будешь лазить
_>Ну я то этот язык не знаю, так что с чего бы они мне были знакомы? ) Не помню чтобы я натыкался на что-то непонятное в русских локализациях IDE.
Ага VS с русской локализацией. это ужас. Эти дебилы локализовали сообщения компилятора и линкера.
Я вот совсем недавно узнал, что такое "компоновка".
Здравствуйте, alex_public, Вы писали:
X>>IDE, использующих clang, я пробовал всего одну — QtCreator. и да, он вразы быстрее чем Netbeans. проверь. _>Попробовал поставить и пока немогу оценить качество автодополнения, т.к. он парсит мне исходники как для старого стандарта (ну т.е. я это подозреваю, т.к. скажем cout он видит правильно) и соответственно например класса thread не видно и т.д.
В QTCreator есть два режима — с моделью кода на clang и их собственной.
По умолчанию стоит их собственная — она работает очень быстро, но неточно. Если поставить clang'овскую, то автодополнение и подсветка ошибок начинают работать идеально (я не нашёл ни единой ошибки в сложном коде). Но до ужаса медленно, но моём лэптопе показ вариантов дополнения занимает секунду-две в лучше случае (в худшем до 10 секунд).
Здравствуйте, 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", но это как бы совсем другое дело.
Здравствуйте, 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, инспекций, и тд — это в целом можно пошарить вместе с проектом в команде, поэтому имеет смысл держать рядом с проектом.
Здравствуйте, 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, Вы писали:
_>Я к тому, что мы сейчас находимся на русскоязычном форуме. Пишем по русски. И вроде как вполне не плохо друг друга понимаем... )
И как это может мне помочь понять, что имели в виду переводчики, когда переводили интерфейс, если я только англоязычные всю жизнь видел? Там же половина слов либо переводится неоднозначно, либо не имеет прямых русских аналогов, и сиди-думай, что бы это значило, или ищи полчаса нужный пункт меню.
_>Да, кстати, а зачем гуглить ошибки компилятора? Там же собственно всё нужное и так написано (и не важно на каком языке) в самой ошибке.
Иногда недостаточно, хочется узнать не что за ошибка, а как лечить применительно к конкретной библиотеке.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, Ops, Вы писали:
Ops>И как это может мне помочь понять, что имели в виду переводчики, когда переводили интерфейс, если я только англоязычные всю жизнь видел? Там же половина слов либо переводится неоднозначно, либо не имеет прямых русских аналогов, и сиди-думай, что бы это значило, или ищи полчаса нужный пункт меню.
Да? ) Т.е. на форуме ты тут пишешь "я сделал file open и потом запустил debug"? ) Или может всё же по другому пишешь? )
Здравствуйте, alex_public, Вы писали:
_>У вас какая-то путаница в голове: слиты в единое целое система сборки (которая в принципе должна быть независима от ide) и система проектов ide (хранящая настройки проекта нужные для ide).
Наоборот, путаница у вас. В CLion разделена модель проекта (то, что необходимо для его сборки) и опции IDE (code style, настройки контроля версий, цвета и размеры шрифтов, прочие ненужные для сборки вещи). Модель читается из CMake-файла, т.к. именно там написано как скомпилировать каждый файл и что перед этим нужно сделать.
_>Никто не предлагает писать свою систему сборки. А вот написать свою систему проектов (т.е. по сути просто сохранение/востановление пары опций) явно не помешало бы. При таком раскладе не надо было бы страдать парсингом конфига для сборки и соответственно можно было бы одним простейшим движением (возможностью запуска произвольной команды при построение) поддержать сразу все существующие системы сборки.
Как вы себе представляете поддержку "простейшим движением" какого-нибудь средней руки проекта, скажем, самого CMake? Там нужно заголовочники перед компиляцией погенерить (иначе остальные файлы просто не распарсить), для нескольких множеств файлов составить соответствующие наборы опций компиляции (в общем случае у каждого файла этот набор свой), сам компилятор выбрать (у них разные built-in функции/макросы и IDE должна их видеть именно такими и именно для этой версии компилятора). Теперь умножайте это в несколько раз, ибо есть релизная сборка, дебажная, специальная сборка для ООО "Вектор", сборка под другую платформу, под другую архитектуру и т.п. Не от безделья же люди пишут километры конфигов в CMakeLists.txt . Теперь вы предлагаете то же самое описать руками второй раз через некие настройки, которые никому, кроме IDE не нужны. Сколько найдется желающих делать работу дважды, сколько будет у такой IDE пользователей?
Конечно, необходимо поддерживать и другие модели проекта, в том числе простейшую, где можно открыть папку с лабой студента, дописать header search paths, и все полетит. Но сначала придется пилить CMake, т.к. большинство программистов хотят открывать не HelloWorld и laba-3, а LLVM и InsightToolkit.
_>Более того, у вас такая система проектов похоже уже есть прямо сейчас (судя по тексту ниже), только она не имеет такого официального названия (ну да, "специфичные для проекта code style" — это конечно совсем другое... ). Так что я вдвойне не понимаю это ваше странное решение.
Никакого отношения к структуре проекта эти опции не имеют. Они нужны только CLion (и даже он без них проживет на стандартных значениях), а остальному миру не нужны. Поэтому живут отдельно.
Здравствуйте, Ops, Вы писали:
Ops>Есть и другие примеры. Например, знаешь, что такое "иерархия вызовов"? Это так call stack обозвали. Или вот "панель элементов" — toolbox. Попробуй угадай. Ops>А если в настройки проекта залезть, то сидишь и думаешь, что бы эта настройка значила, inline — оно и в индии inline, накрайняк инлайн, а оказывается "подставляемая". Тьфу.
А чем не нравится перевод то? ) Или нравится заменять всё англицизмами?
Вообще, если где-то в нашей области и существуют неустоявшиеся до конца термины, то это вина исключительно нас с вами (в смысле русского сообщества программистов), потому как, а кто собственно кроме нас будет определять эти стандарты? )
Здравствуйте, alex_public, Вы писали:
_>А чем не нравится перевод то? ) Или нравится заменять всё англицизмами?
Так первые 2 примера просто некорректны, а 3-й — это уже плюсы начали переводить. Дальше смотреть не стал, переключил обратно на английский, потому как бяка.
_>Вообще, если где-то в нашей области и существуют неустоявшиеся до конца термины, то это вина исключительно нас с вами (в смысле русского сообщества программистов), потому как, а кто собственно кроме нас будет определять эти стандарты? )
В смысле неустоявшиеся? Call stack — это стек вызовов, или просто стек, в подходящем контексте. А когда в это лезут литературоведы, да еще и язык программирования переводить пытаются, то нафиг мне такое счастье, и с английским неплохо.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, noone, Вы писали:
N>Наоборот, путаница у вас. В CLion разделена модель проекта (то, что необходимо для его сборки) и опции IDE (code style, настройки контроля версий, цвета и размеры шрифтов, прочие ненужные для сборки вещи). Модель читается из CMake-файла, т.к. именно там написано как скомпилировать каждый файл и что перед этим нужно сделать.
Собственно вы повторили в точности мою мысль, только своими словами. Задам вам простейший вопрос уже в вашей терминологии: а зачем ide читать "модель проекта"? Сборкой то в любом случае занимается не она, а сторонняя система сборки.
N>Как вы себе представляете поддержку "простейшим движением" какого-нибудь средней руки проекта, скажем, самого CMake? Там нужно заголовочники перед компиляцией погенерить (иначе остальные файлы просто не распарсить), для нескольких множеств файлов составить соответствующие наборы опций компиляции (в общем случае у каждого файла этот набор свой), сам компилятор выбрать (у них разные built-in функции/макросы и IDE должна их видеть именно такими и именно для этой версии компилятора). Теперь умножайте это в несколько раз, ибо есть релизная сборка, дебажная, специальная сборка для ООО "Вектор", сборка под другую платформу, под другую архитектуру и т.п. Не от безделья же люди пишут километры конфигов в CMakeLists.txt. Теперь вы предлагаете то же самое описать руками второй раз через некие настройки, которые никому, кроме IDE не нужны. Сколько найдется желающих делать работу дважды, сколько будет у такой IDE пользователей?
Я вроде бы достаточно чётко описал реализацию этого простейшего движения (собственно оно имеется во всех конкурирующих IDE). Это возможность запуска произвольной команды (а будет это make/nmake/waf/scons или вообще bat файл решает пользователь в простейшей настройке) по нажатию кнопки build в IDE. В таком случае будут одинаково отлично работать и студенческая поделка и проект с километровым конфигом в CMakeLists.txt.
Кстати, нечто очень отдалённое там всё же реализовано. Только почему-то не в настройках build, а в настройках run/debug. Там можно добавить произвольную команду перед запуском и даже убрать стандартный шаг build. Однако это всё же решение через задницу. Тем более, что без CMakeLists.txt анализатор кода всё равно работать не будет.
Что касается настроек, необходимых для работы анализатора кода, то это совсем другой вопрос. Настройка там всегда одинаковая, тривиальная (всего то пара опций) и во всех нормальных IDE делается за пару минут, в том числе и под несколько конфигураций. Я это делал не раз и в разных IDE. И никаких сложностей не встречал.
N>Никакого отношения к структуре проекта эти опции не имеют. Они нужны только CLion (и даже он без них проживет на стандартных значениях), а остальному миру не нужны. Поэтому живут отдельно.
Ну так и настройки анализатора кода нужны только CLion — вот там им и самое место.
Здравствуйте, Ops, Вы писали:
Ops>В смысле неустоявшиеся? Call stack — это стек вызовов, или просто стек, в подходящем контексте. А когда в это лезут литературоведы, да еще и язык программирования переводить пытаются, то нафиг мне такое счастье, и с английским неплохо.
Вооот. Т.е. нормальные термины вполне себе существуют и ты даже сам их озвучил. Т.е. суть проблемы в том, что данный конкретный перевод почему-то делали криворукие специалисты. А не в самом факте идеи локализации подобного ПО.
Кстати, я тут замечал, что в этом смысле "энтузиастские" (сделанные пользователями продукта, при поддержке такой возможности производителем) переводы частенько гораздо более качественнее коммерческих от мегакорпораций.
Все эти термины и названия типа call stack, по сути — компьютерный жаргон. Смысла придумывать еще и русские переводы — нет никакого. Не так уж и много этих английских названий, запомнить для программиста — не вопрос. К тому же переводы частенько неоднозначные, кривые или все равно состоят из других англицизмов
Здравствуйте, alex_public, Вы писали: _>Вооот. Т.е. нормальные термины вполне себе существуют и ты даже сам их озвучил. Т.е. суть проблемы в том, что данный конкретный перевод почему-то делали криворукие специалисты. А не в самом факте идеи локализации подобного ПО.
Не только качество перевода, еще дело в том, что большая часть документации, ответов на вопросы, и т.п., существует только на английском. Наверняка есть еще факторы, из-за которых пользователи крупных профессиональных пакетов не очень любят локализацию. Вот знакомый дизайнер говорит, что фотошоп у них используют тоже в основном английский.
_>Кстати, я тут замечал, что в этом смысле "энтузиастские" (сделанные пользователями продукта, при поддержке такой возможности производителем) переводы частенько гораздо более качественнее коммерческих от мегакорпораций.
Тут не буду спорить, статистику не набирал.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, alex_public, Вы писали:
_>Здравствуйте, noone, Вы писали: _>Собственно вы повторили в точности мою мысль, только своими словами. Задам вам простейший вопрос уже в вашей терминологии: а зачем ide читать "модель проекта"? Сборкой то в любом случае занимается не она, а сторонняя система сборки.
Я в прошлом посте на пол-страницы распинался, рассказывая зачем. Потому что в C++ нет исходных файлов, а есть зависящие от контекста единицы компиляции. Для того, чтобы понять что написано в этой конкретной единице, вы должны повторить все шаги системы сборки и получить на входе все нужные опции и такое же, как при сборке, расположение/содержание других файлов на диске. Существуют (полу)декларативные модели проекта, откуда это можно дешево вычитывать (см. VS, Xcode), но CMake к ним не относится, его приходится заставлять такую модель генерировать (см. загадочная папка).
_>Я вроде бы достаточно чётко описал реализацию этого простейшего движения (собственно оно имеется во всех конкурирующих IDE). Это возможность запуска произвольной команды (а будет это make/nmake/waf/scons или вообще bat файл решает пользователь в простейшей настройке) по нажатию кнопки build в IDE. В таком случае будут одинаково отлично работать и студенческая поделка и проект с километровым конфигом в CMakeLists.txt.
Это программы будут отлично собираться и работать. А IDE работать не будет, потому что нужных настроек компиляции и правильного окружения у нее нет.
_>Что касается настроек, необходимых для работы анализатора кода, то это совсем другой вопрос. Настройка там всегда одинаковая, тривиальная (всего то пара опций) и во всех нормальных IDE делается за пару минут, в том числе и под несколько конфигураций. Я это делал не раз и в разных IDE. И никаких сложностей не встречал.
Возможно, что у вас в программе пара опций. Это очень хорошо, вы легко напишете двухстрочный CMakeLists.txt и вот вам паллиатив до момента поддержки более удобных для вас моделей. Но CLion должен поддерживать все корректно настроенные проекты, и показывать при этом что-то более осмысленное, чем редактор с подсветкой текста. Вы предлагаете разработчикам LLVM переписать все опции под все платформы в удобном для IDE виде, а потом поддерживать одно и то же в двух разных местах? Возьмите упоминавшийся проект http://www.itk.org/ и сформулируйте "пару опций", которые для каждой единицы компиляции эквивалентны тем, что получаются у CMake сейчас. Плюс позволяют как-то легко сгенерировать необходимые файлы из имеющихся болванок. Для 4-х платформ — Win 64, OS X 32, OS X 64, Linux 32 (всякие IRIX и AIX пока пропустим), и двух фронтендов — GCC, Clang.
_>Ну так и настройки анализатора кода нужны только CLion — вот там им и самое место.
Настройки анализатора кода ("отслеживать неприсвоенные переменные или забить", "искать бесконечные циклы или забить" и т.п.) как раз в .idea и хранятся. А настройки компиляции и окружения, без которых до анализа кода дело не дойдет, хранятся в CMakeLists.txt, где их все равно уже пишет и поддерживает автор программы. При открытии проекта они распаковываются с помощью CMake во временную папку в относительно удобоваримом для CLion виде.
Здравствуйте, Ops, Вы писали:
Ops>Не только качество перевода, еще дело в том, что большая часть документации, ответов на вопросы, и т.п., существует только на английском. Наверняка есть еще факторы, из-за которых пользователи крупных профессиональных пакетов не очень любят локализацию. Вот знакомый дизайнер говорит, что фотошоп у них используют тоже в основном английский.
Ну это скорее такое следствие особенностей развития в 90-ые годы. )))
Но с этим надо бороться улучшением качества переводов, а руганью на разработчиков за попытку сделать эти переводы.
Кстати, вообще говоря на нашей планете есть всего 3 языка, которые обладают полным набором необходимой терминологии для всей современной науки и инженерного дела. В других языках просто нет нужных понятий. Т.е. если учиться не на одном из них, то просто физически невозможно стать специалистом высшего уровня. Так вот русский — это один из этих трёх. И очень не хотелось бы, чтобы благодаря халтурной работе наших компьютерщиков (это я не про тебя, а про тех, кто делает сомнительные переводы или же использует англицизмы на каждом шагу) таких языков стало бы только два... Хотя я уже вижу что такого не будет — маятник "моды" уже некоторое время назад как пошёл в обратную сторону. )
Здравствуйте, noone, Вы писали:
N>Я в прошлом посте на пол-страницы распинался, рассказывая зачем. Потому что в C++ нет исходных файлов, а есть зависящие от контекста единицы компиляции. Для того, чтобы понять что написано в этой конкретной единице, вы должны повторить все шаги системы сборки и получить на входе все нужные опции и такое же, как при сборке, расположение/содержание других файлов на диске. Существуют (полу)декларативные модели проекта, откуда это можно дешево вычитывать (см. VS, Xcode), но CMake к ним не относится, его приходится заставлять такую модель генерировать (см. загадочная папка).
У нас странная дискуссия. Вы рассказываете почему это точно не может работать из каких-то общетеоретических соображений, а я вам отвечаю что вот оно у меня перед глазами отлично работает. Может стоит просто взять и попробовать самому указанные мною схемы? ) А то меня как-то напрягает тратить своё время на убеждение людей в том, что это земля вращается вокруг солнца, а не наоборот.
N>Это программы будут отлично собираться и работать. А IDE работать не будет, потому что нужных настроек компиляции и правильного окружения у нее нет.
И что мешает настроить это в окошке IDE? Как собственно и реализовано во всех конкурентах CLion? )
N>Возможно, что у вас в программе пара опций. Это очень хорошо, вы легко напишете двухстрочный CMakeLists.txt и вот вам паллиатив до момента поддержки более удобных для вас моделей. Но CLion должен поддерживать все корректно настроенные проекты, и показывать при этом что-то более осмысленное, чем редактор с подсветкой текста. Вы предлагаете разработчикам LLVM переписать все опции под все платформы в удобном для IDE виде, а потом поддерживать одно и то же в двух разных местах? Возьмите упоминавшийся проект http://www.itk.org/ и сформулируйте "пару опций", которые для каждой единицы компиляции эквивалентны тем, что получаются у CMake сейчас. Плюс позволяют как-то легко сгенерировать необходимые файлы из имеющихся болванок. Для 4-х платформ — Win 64, OS X 32, OS X 64, Linux 32 (всякие IRIX и AIX пока пропустим), и двух фронтендов — GCC, Clang.
Ещё раз: у вас общетеоретические рассуждения, почему это не может работать (а вы хоть пробовали?), а у меня конкретная практика перед глазами. Причём на проекте использующем тяжёлые кроссплатформенные (т.е. куча этих самых ifdef в них) библиотеки типа boost, wxWidgets, OpenCV и имеющим много разных конфигураций сборки. Да, и кстати собирающимся под кучу разных платформ (правда это никак не пересекается с конфигурациями — каждая из них собирается везде). Так вот в Netbeans анализатор кода превосходно всё видит и для этого потребовалась всего несколько минут на его настройку (те самые указания каталогов заголовочных файлов и директив препроцессора). Более того, до этого у меня не было проблем с аналогичным в Eclipse, а до этого в VisualStudio. Почему-то во всех приличных IDE есть такие настройки. Наверное потому, что они не предназначены для "серьёзных" проектов?
N>Настройки анализатора кода ("отслеживать неприсвоенные переменные или забить", "искать бесконечные циклы или забить" и т.п.) как раз в .idea и хранятся. А настройки компиляции и окружения, без которых до анализа кода дело не дойдет, хранятся в CMakeLists.txt, где их все равно уже пишет и поддерживает автор программы. При открытии проекта они распаковываются с помощью CMake во временную папку в относительно удобоваримом для CLion виде.
Кстати говоря, настройки каталогов заголовочных файлов обычно делаются у меня даже не под проект (ну точнее там тоже настраивается иногда, но уже мелочи по папкам внутри проекта, а не по внешним библиотекам), а просто в IDE, глобально на все проекты. Так что настройка конкретного проекта чаще всего сводится к банальным указаниям специфических опций препроцессора (далеко не всех, что передаются компилятору про сборки, а только влияющих на анализ кода) под каждую конфигурацию.
весь тред не читал, может быть уже и ответили.
вопрос в том, почему в линуксе один и тот же шрифт который в kate и qtcreator выглядит превосходно, в Clion — просто вырвиглазие?!
какие шрифты не пробовал — все вырвиглазные.
чо делать-то?
пачка бумаги А4 стОит 2000 р, в ней 500 листов. получается, лист обычной бумаги стОит дороже имперского рубля =)
это ужас. Эти дебилы локализовали сообщения компилятора и линкера. 
и где здесь сеть?
— конечно тоже ерунда, по сравнению со стандартным окном винды, но во всяком случае все необходимые элементы имеются.
