Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 51
Очень любопытная картина: после сообщения о том, что Вы пришли в область, в которой ничего не смыслите, Вы сразу же классифицировали всех несогласных с Вашими решениями на три не очень приятные категории. Вы не рассматриваете четвертую категорию — тех, кто уже крутится в данной области, и лучше знает, что больше подойдет для задачи?
Если бы Вы выбрали IDE, которая используется как раз для разработки десктопа под Windows, в этой статье вместо двадцатиминутной возни с CMake в VS Code Вы бы уже писали игрушки.
Если бы Вы выбрали IDE, которая используется как раз для разработки десктопа под Windows, в этой статье вместо двадцатиминутной возни с CMake в VS Code Вы бы уже писали игрушки.
- Отрицание
- Гнев
- Торг
- Депрессия
- Принятие
- CMake+VSCode во всех проектах
Это к чему?
И VS Code — это не та IDE, которую используют для десктопа под Windows.
И VS Code — это не та IDE, которую используют для десктопа под Windows.
Какую IDE используют для декстопа под Windows?
Насколько я знаю, обычно используют VS. Community edition безусловно-бесплатная, имеет очень развитый функционал, не лагает, ну а для профилирования и компьютерной графики там вообще все шикарно (по сравнению с другими IDE). Но, насколько я понимаю, все это перекрывается одним большим минусом — ее сделали не в JetBrains?
Я использую VSCode… За соседним местом юзают SublimeText, ещё неподалёку пару vim'еров и FAR'еров, ну иногда вижу VS…
Для разработки desktopa под Windows? Ну мне честно не понятна Ваша мотивация. А остальное что Вы назвали — это вроде вообще редакторы, а не IDE.
Просто используется своя система сборки + большой проект. CLion'ы и прочие его не могут понять, VS слишком тормознута(на мой взгляд). VSCode + некоторый набор плагинов = неплохой инструмент, который мне позволяет писать + компилять/дебажить под 3 платформы сразу(Win, Lin, Mac)…
Ну и расскажите мне что такое IDE если не редактор с плагинами? :)
Ну и расскажите мне что такое IDE если не редактор с плагинами? :)
А можно подробней про набор плагинов? Ну, если это не какая-то коммерческая тайна, конечно. (Что вполне может быть, судя по фразе «большой проект»). И если это какая-то загадочная вундервафля, то нафига она :-)
Ну, если и сборка кастомная, и плагинов по-находили, то VS Code может быть и неплохой инструмент. Но все это у Вас есть только потому, что кто-то когда-то потратил уйму времени на то, что бы все это сделать. И в этом отличие Вашего понимания IDE от моего. ИМХО IDE — это Integrated Development Environment, то есть после ее запуска я должен иметь возможность редактировать/компилировать/запускать/дебажить/в случае VS еще и мало-мальски профилировать CPU и дебажить графику. Максимум что нужно сделать — пару настроек на вкус и цвет.
IDE на мой взгляд плохо масштабируются:
1) не умеют из коробки компилировать/отлаживать кроссплатформенные проекты, Вам придётся тратить время на то, чтобы заставить их это уметь.
2) многие не умеют из коробки в мультиязычность, иногда умеют но не в то подмножество, что необходимо
3) привязывают проект к себе — создают всякие воркспейсы, солюшены и прочее
4) в силу особенностей строения человеческого мозга не могут угодить всем сразу — заметно если над проектом работают больше двух человек, особенно заметно если больше 200…
В итоге имеем что несмотря на все преимущества не покрывают всех требуемых при масштабирование сценариев и вместо них начинают использоваться модифицируемые редакторы, которые из коробки дают терминал для запуска консольных утилит, возможность добавить подсветку + автокомплит для любого необходимого множества языков и расширяемы плагинами для отладки.
1) не умеют из коробки компилировать/отлаживать кроссплатформенные проекты, Вам придётся тратить время на то, чтобы заставить их это уметь.
2) многие не умеют из коробки в мультиязычность, иногда умеют но не в то подмножество, что необходимо
3) привязывают проект к себе — создают всякие воркспейсы, солюшены и прочее
4) в силу особенностей строения человеческого мозга не могут угодить всем сразу — заметно если над проектом работают больше двух человек, особенно заметно если больше 200…
В итоге имеем что несмотря на все преимущества не покрывают всех требуемых при масштабирование сценариев и вместо них начинают использоваться модифицируемые редакторы, которые из коробки дают терминал для запуска консольных утилит, возможность добавить подсветку + автокомплит для любого необходимого множества языков и расширяемы плагинами для отладки.
1) В VS 17 вроде есть Linux Toolkit. Ну и вообще вряд ли Вы потратите больше времени с IDE, чем с обычным редактором.
2) VS умеет в C++, C#, Python, JavaScript, это то что я с ходу назову. Вроде норм мультиязычность.
3) Что в этом плохого?
4) Ну такими темпами и язык программирования то наверняка не всем по душе) И операционка/политика компании/положение звезд на небе. Отчасти поэтому смотрят и в сторону популярности IDE среди программистов, и VS Code там не на первом месте.
Вообще, если у Вас кроссплатформенный проект с тонной условностей вроде своей build-системы и каких-то редких диалектов языков, то VS и впрямь может быть не лучшим выбором. Но согласитесь, что автор проблемы может испытать только в четвертом пункте)
2) VS умеет в C++, C#, Python, JavaScript, это то что я с ходу назову. Вроде норм мультиязычность.
3) Что в этом плохого?
4) Ну такими темпами и язык программирования то наверняка не всем по душе) И операционка/политика компании/положение звезд на небе. Отчасти поэтому смотрят и в сторону популярности IDE среди программистов, и VS Code там не на первом месте.
Вообще, если у Вас кроссплатформенный проект с тонной условностей вроде своей build-системы и каких-то редких диалектов языков, то VS и впрямь может быть не лучшим выбором. Но согласитесь, что автор проблемы может испытать только в четвертом пункте)
> 3) привязывают проект к себе — создают всякие воркспейсы, солюшены и прочее
> 3) Что в этом плохого?
Собственно, в этом и был смысл всей статьи. Что есть способ сделать так, чтобы не быть завендорлоченным на конкретное решение.
Чем это плохо? Тем что вендор начинает вертеть тобой как хочет, как хвост собакой. Если же ты ни от чего не зависишь, а используешь свободный кроссплатформенный софт, то как только вендор начал трепыхаться — ты прокручиваешь его на оси и отправляешься в любые конкурирующие решения.
Как вы поняли, я сам не крестовик, а джавист. Имеется огромный опыт вот в этом. У нас даже Java — это в первую очередь набор спецификаций, относительно которых разные вендоры производят библиотеки и виртуальные машины, удовлетворяющие этим спецификациям. Спецификация — первична, конкретное решение — вторично. Очень удобно. Ты свободен как птица выбирать самое выгодное решение.
> 3) Что в этом плохого?
Собственно, в этом и был смысл всей статьи. Что есть способ сделать так, чтобы не быть завендорлоченным на конкретное решение.
Чем это плохо? Тем что вендор начинает вертеть тобой как хочет, как хвост собакой. Если же ты ни от чего не зависишь, а используешь свободный кроссплатформенный софт, то как только вендор начал трепыхаться — ты прокручиваешь его на оси и отправляешься в любые конкурирующие решения.
Как вы поняли, я сам не крестовик, а джавист. Имеется огромный опыт вот в этом. У нас даже Java — это в первую очередь набор спецификаций, относительно которых разные вендоры производят библиотеки и виртуальные машины, удовлетворяющие этим спецификациям. Спецификация — первична, конкретное решение — вторично. Очень удобно. Ты свободен как птица выбирать самое выгодное решение.
Ну VS уже больше 15 лет существует, никто никем не вертит. А даже если начнет — да, придется один раз конвертировать solution VS в solution чего-то другого, но Вы это сделаете один раз, причем, скорее всего, не вручную, а автоматически. С другой стороны, Вам не придется все тестить в десятке IDE и мучиться с CMake.
1) VS17 не пробовал — для линукса на винде есть wsl, вот его использую активно.
2) Но не умеет в Go, а он тоже нужен.
По остальному чуть более широко:
Я заметил что все достаточно большие проекты рано или поздно приходят к виду папочки с кодом, ресурсами и тулчейном/скриптами под тулчейн — так оказывается удобнее развиваться и расти. Я думаю можно взять в качестве примера любой известны opensource проект — там внутри будет папка с кодом, список зависимостей и набор команд, которые надо ввести в консоль чтобы проект собрать (аля make && make install).
Вводя дополнительные ограничения в виде требуемой IDE для сборки или чего-то вроде вы во первых создаёте дополнительные точки отказа (а вдруг с этой IDE что-то случится) которые вы слабо контролируете + увеличиваете порог входа для нового человека в разработке.
В итоге простая папочка с кодом и скриптами открывается любым адеквватным редактором, который помогает с подсветкой, автодополнением и подсказками, да хоть и без них, а консоль позволяет ввести нужный набор команд, чтобы получить изменённую программу и тестировать её.
Но если проект небольшой, или в ранней стадии развития то да, использование правильной IDE может дать ощутимый пинок, забрав на себя львиную долю проблем по управлению сборкой, отладке и тестированию.
Кстати в этом плане современные IDE, тот же CLion, пытаются открывать вот такие папочки с кодом если сборка построена распространённых системах(вроде того-же make и CMake), что у них неплохо получается, но всё равно они по прежнему не подходят для гигантских проектов с миллонами loc и кастомной сборкой.
2) Но не умеет в Go, а он тоже нужен.
По остальному чуть более широко:
Я заметил что все достаточно большие проекты рано или поздно приходят к виду папочки с кодом, ресурсами и тулчейном/скриптами под тулчейн — так оказывается удобнее развиваться и расти. Я думаю можно взять в качестве примера любой известны opensource проект — там внутри будет папка с кодом, список зависимостей и набор команд, которые надо ввести в консоль чтобы проект собрать (аля make && make install).
Вводя дополнительные ограничения в виде требуемой IDE для сборки или чего-то вроде вы во первых создаёте дополнительные точки отказа (а вдруг с этой IDE что-то случится) которые вы слабо контролируете + увеличиваете порог входа для нового человека в разработке.
В итоге простая папочка с кодом и скриптами открывается любым адеквватным редактором, который помогает с подсветкой, автодополнением и подсказками, да хоть и без них, а консоль позволяет ввести нужный набор команд, чтобы получить изменённую программу и тестировать её.
Но если проект небольшой, или в ранней стадии развития то да, использование правильной IDE может дать ощутимый пинок, забрав на себя львиную долю проблем по управлению сборкой, отладке и тестированию.
Кстати в этом плане современные IDE, тот же CLion, пытаются открывать вот такие папочки с кодом если сборка построена распространённых системах(вроде того-же make и CMake), что у них неплохо получается, но всё равно они по прежнему не подходят для гигантских проектов с миллонами loc и кастомной сборкой.
Какие функции VS наиболее полезны для компьютерной графики? Там есть что-нибудь про поиск пути и коллизии? В аргументации можно воспользоваться возможностями Enterprise Edition, если они помогут. Заранее спасибо.
Проблемы тех, кто пользуется cmake. Нормальный make CLion не поддерживает.
По хардкору за IDE, Cmake, и моё разочарование в животныхЧем вам так не угодили предлоги «о» и «про», что вы стремитесь этим нелепым и тупым «за» их заменить? Неуважение к читателям? Чтобы они не сразу поняли смысл?
Давайте демократически устроим здесь голосование. С одной стороны, кажется что выражение «топить за X» прочно вошло в разговорную речь. С другой стороны, ну может у меня круг общения такой.
Если этот комментарий наберет 25 плюсов я поменяю «за» на что-нибудь другое. На «про IDE», скорей всего.
Если этот комментарий наберет 25 плюсов я поменяю «за» на что-нибудь другое. На «про IDE», скорей всего.
Просто не надо лексикон гопоты тащить и сюда.
Присоединяюсь к Revertis. И, чтоб два раза не вставать: на ЛОРе никто за Вами не занимал? Вроде аккаунт крайний.
Извините, глаза ест (с).
Извините, глаза ест (с).
Как установить CMake и Ninja
Главное — зачем.
Допустим, с CMake все понятно — это кроссплатформенная замена autoconf. А вот зачем нужен ninja — не совсем ясно. MSys вроде как идет с утилитой make, под которую CMake вполне себе умеет генерировать файлы: cmake -G «UNIX Makefiles». Если отказаться от сурового опенсорца и собирать MSVC компилятором с тамошней утилитой nmake, то CMake и такое умеет: cmake -G «NMake Makefiles».
А в чем смысл юзать ninja? Непонятно.
Если вы так же, как и я, живёте в компьютере, а не только включаете его в рабочие часы, предлагается следующая схема: перед началом программирования добавлять MinGW в PATH, а после — убирать. Для облегчения процесса нужно сделать два батника, которые можно запускать двойным щелчком:
Все это уже придумано до вас. Если интересно — замарайте руки установкой visual studio community и посмотрите, как там реализован developer command prompt. По факту — это батники, которые запускаются по щелчку и выставляют огромную кучу всякого полезного. Более того, в зависимости от аргументов тамошние батники умеют выставлять окружение для разработки под разные платформы (x86, x64, arm). Самый цимес — все это выставляется только внутри запущенной консольки и не уродует систему.
Т.е. если вам действительно хочется собирать проекты из командной строки, можно разложить по десктопу батники: «g++ x64», «g++ x86», «msvc x64», «msvc x86» и т. п. Ткнул — открылось окно консольки, где все уже настроено для запуска нужной версии компилятора с нужными путями.
Тогда можно одновременно собирать, например, 32-битные и 64-битные бинари в разных окошках.
Но всё-таки, разрабатывать без IDE — не дело.
Заблуждение.
> Заблуждение.
А вот можете это подробней раскрыть? Выше по трэду меня picul пытается отшлёпать по заднице, и в суровой битве нужны суровые аргументы!
> Если интересно — замарайте руки… developer command prompt.
Да, в этом надо будет обязательно покопаться.
> Главное — зачем.
Цель статьи была показать, что ты не завендорлочен на конкретное несвободное коммерческое IDE. Многие отказываются использовать такой софт сразу же с порога, потому что «если мы подсядем на X, то потом уже не слезть, а вдруг вендор будет нами крутить как хочет». А тут сразу ясно, что как только вендор решит вами покрутить, вы отправите его в длительное пешее эротическое путешествие и просто перепрыгните на любое конкурирующее решение из громадного спектра.
Ну и в частности, это моя попытка самооправдания. Потому что вместо того, чтобы следовать слову Столлмана и использовать только свободное ПО, в дальнейших выпусках будет в основном CLion и MSVS. Что несколько зашкварно, конечно.
А вот можете это подробней раскрыть? Выше по трэду меня picul пытается отшлёпать по заднице, и в суровой битве нужны суровые аргументы!
> Если интересно — замарайте руки… developer command prompt.
Да, в этом надо будет обязательно покопаться.
> Главное — зачем.
Цель статьи была показать, что ты не завендорлочен на конкретное несвободное коммерческое IDE. Многие отказываются использовать такой софт сразу же с порога, потому что «если мы подсядем на X, то потом уже не слезть, а вдруг вендор будет нами крутить как хочет». А тут сразу ясно, что как только вендор решит вами покрутить, вы отправите его в длительное пешее эротическое путешествие и просто перепрыгните на любое конкурирующее решение из громадного спектра.
Ну и в частности, это моя попытка самооправдания. Потому что вместо того, чтобы следовать слову Столлмана и использовать только свободное ПО, в дальнейших выпусках будет в основном CLion и MSVS. Что несколько зашкварно, конечно.
Цель статьи была показать, что ты не завендорлочен на конкретное несвободное коммерческое IDE.
Я понимаю. Непонятен конкретный выбор ninja в качестве системы сборки. CMake — это прекрасный инструмент, практически не имеющий альтернатив, если проект кроссплатформенный. CMake умеет генерировать файлы под практически все системы сборки (включая msbuild). Посему остается непонятным, зачем нужно вводить дополнительный инструмент и какие преимущества он дает.
А вот можете это подробней раскрыть?
Если совсем подробно, то нужна будет целая статья. А то и не одна.
Если вкратце — то по моему личному опыту и мнению, разработка в IDE способна снизить самодисциплину. А она очень важна, когда речь идет о качестве кода.
Поясню, о чем речь. Когда программист пишет код, он пишет его в первую очередь для других программистов. Именно для того, чтобы код легче читался и понимался, придуманы тонны coding style guide'ов. Соблюдение всех этих правил и требует от программиста самодисциплины.
IDE слишком многое делает для и за программиста. Довольно часто это приводит к тому, что программист в упор не понимает, зачем нужно правильное оформление кода. Зачем лишние пробелы? Все же и так хорошо видно — IDE подсвечивает! Зачем разбивать длинные строки, ведь в IDE же все автоматически переносится? Да еще и экран у меня широкий — мне удобнее, когда весь код в одну строчку! Зачем разносить по файлам разные функции — IDE же предлагает их все в одном файле создавать! И так далее.
Неполный перечень примеров из реальной жизни:
— чувак в упор не понимал, почему функция с 20 аргументами — это плохо. «Все аргументы же в подсказках описываются, когда код вводишь!».
— другой товарищ в упор не понимал, зачем нужно разбивать на несколько файлов исходник в 200 Кб. При том, что там содержались функции, абсолютно друг с другом не связанные логически. «А чо, вот же слева есть навигатор — любая функция там легко находится, и не надо весь файл скроллить!».
— еще один гражданин упорно писал код строками длиной в 200-300 символов, да еще и с комментами на русском языке. «У меня же все видно!». Его не смущало даже то, что комментарии при коммите превращались в фарш, ибо сервер стоял в Германии и не умел работать с кириллицей. Попытки достучаться до здравого смысла наталкивались на железобетонную стену: «у меня все нормально, проблема на той стороне».
Это все, конечно, мелочи. Но с вышеупомянутыми гражданами проблемы были и посерьезнее: коммиты, которые ломают билд; нежелание осваивать новые инструменты, если они не интегрированы в их IDE; конфликтное поведение и «закукливание» в ответ на любую критику.
Я не утверждаю, что все беды от IDE. Но в некоторых случаях «прикипание» к IDE может привести к обострению проблем у асоциальных и аутичных личностей, а следовательно — к снижению качества их работы.
Помню, один знакомый товарищ намучился с такими вот «вижулятниками» и пошел своим путем: перешел на консольный vim, отключил подсветку синтаксиса и автоматический перенос строк. На его код было любо-дорого взглянуть. Потом, правда, все равно уволился. :)
IDE это в первую очередь инструмент, и чем он лучше, тем производительнее сотрудник. На мой взгляд вам не хватало гайдлайнов/ревью/прекоммитных проверок. Когда сервер тупо не дает коммитить всё что не по код-стайлу, волей-неволей придётся переделывать — с ним то не поспоришь.
IDE это в первую очередь инструмент, и чем он лучше, тем производительнее сотрудник.
Это заблуждение.
Производительность программиста — не в том, чтобы как можно быстрее накодить побольше строчек кода, а в том, чтобы код получился работоспособный и качественный. IDE не помогает ни с первым, ни со вторым.
Даже хуже: подсветка синтаксических ошибок в IDE создает у некоторых граждан иллюзию, что они могут написать корректный код без использования компилятора вообще. Когда в наш проект (на линукс) пришли такие вот IDE-кодеры с вижуал студией, они файлы так и правили по привычке в винде, в студии. И коммитили прямо оттуда, ни разу не удосужившись собрать сборку под линуксом. Ненуачо, ошибок же нету!
К сожалению, рычагов воздействия на них не было (такой вот был местный колорит).
К счастью, продолжалось это недолго по очевидным причинам.
Производительность программиста — не в том, чтобы как можно быстрее накодить побольше строчек кода, а в том, чтобы код получился работоспособный и качественный. IDE не помогает ни с первым, ни со вторым.
Во-первых, «производительность» это про «быстрее = лучше» если не в ущерб корректности/качеству. IDE позволяет писать код быстрее и как правило не в ущерб качеству.
Во-вторых, синтаксические ошибки — тоже ошибки. И другие, которые можно диагностировать на раннем этапе.
Когда в наш проект (на линукс) пришли такие вот IDE-кодеры с вижуал студией, они файлы так и правили по привычке в винде, в студии. И коммитили прямо оттуда, ни разу не удосужившись собрать сборку под линуксом. Ненуачо, ошибок же нету!
Это проблема халатности сотрудников. Вы же не думаете всерьез что в блокноте конкретно они будут писать лучше, корректнее и быстрее?
А еще налицо проблема инфраструктуры. Ничто не мешает вам использовать IDE с clang'овскими диагностиками и компилить самим clang'ом. Ничто не мешает вам использовать IDE, настроенную на удаленную сборку/запуск/отладку. Ничто не мешает вам настроить автосборку и тестирование. А еще ничто не мешает вам, в конце концов, запретить использование VS на linux-проекте. Другие IDE то в чем повинны?
Во-первых, (...)
Во-вторых, (...)
Да-да, все так, все так. Если рассматривать сферического программиста в вакууме.
На практике программисты, как известно,
Это проблема халатности сотрудников. Вы же не думаете всерьез что в блокноте конкретно они будут писать лучше, корректнее и быстрее?
Это не халатность, а скорее протест. Люди искренне не понимали требований.
Что касается блокнота — вы не поверите, но были и такие эксперименты. До конца дошли очень немногие. Тем не менее — код получился лучше, корректнее и читабельнее. Естественно, что скорость была никакая — но не потому, что товарищи резко разучились находить кнопки на клавиатуре. Просто очень много времени ушло на объяснения очевидных вещей: «вот тут у тебя — видишь? — все в кучу слеплено. А если пробельчиков добавить — сразу становится понятнее».
А еще налицо проблема инфраструктуры. Ничто не мешает вам использовать IDE с clang'овскими диагностиками и компилить самим clang'ом.
Это уже не относящиеся к обсуждаемому вопросу мелочи. Лично я считаю, что исходники должны быть отвязаны от любого рода IDE. А это значит, что даже если косоглазый китаец откроет их допотопным vi'ем в текстовой консольке 80х25 — он должен увидеть вполне читаемый код, а не уходящую за край экрана мешанину без единого пробела.
Что касается особенностей моей тогдашней работы — как бы вам объяснить-то покорректнее… Проблема инфраструктуры шерифа (сиречь руководство) не колыхала совершенно. Руководство было в далекой и влажной стране, все офисы были типовыми, вся разработка велась на серверах, которые стояли за много тыщ километров от машины разработчика. На машинах разработчика — винда. Так положено.
Вариантов запустить IDE было ровно два:
1. Поднимаем на винде X Window Server. Пробрасываем на него коннект с серверной машины. Запускаем там Eclipse (или Emacs, или gvim). Уходим пить кофе. К нашему приходу, если повезет, окошки дорисуются.
2. Ставим на локальной машине студию (или Eclipse, или еще что). Ставим в нее плагин, чтобы можно было брать исходники по FTP (другого на серверах нет). Компилять, естественно, не получится. Мучаемся так.
А так, конечно, ни-че-го не мешало нам использовать IDE. :)
Другие IDE то в чем повинны?
Ни в чем. И вижулятина тоже ни в чем не виновата. Я вообще не об инструменте, а о влиянии молотка на неокрепшие умы.
А вот вы своими словами можете аргументировать, чем функция с 20 параметрами плохая, если всё равно есть посветка в IDE? :-)
Сорян что на такой обширный комментарий отвечаю так коротко, но надо как-то употребить слона по кусочкам
Сорян что на такой обширный комментарий отвечаю так коротко, но надо как-то употребить слона по кусочкам
IDE с подсветкой вовсе не обязательно будет у тех, кто потом будет поддерживать этот код. А без подсветки разобраться в вызовах такой функции малореально. Особенно если кто-то удалил, скажем, один аргумент из середины списка или перепутал порядок аргументов. Компилятор вовсе не обязательно в таких случаях выдаст ошибку (типы данных можно и подпривести к нужным, а некоторые аргументы могут иметь значения по умолчанию).
Ну и — очевидно — чем длиннее список аргументов, тем больше вероятность, что программист что-нибудь напутает при вызове.
Ну и — очевидно — чем длиннее список аргументов, тем больше вероятность, что программист что-нибудь напутает при вызове.
Заблуждение
Ну почему же, вдруг разработчик операторы ЯП не помнит?
Почему в статье указана цена CLion за месяц использования для бизнеса. Для индивидуального использования цена 8,90$ в месяц, и если уж говорить о цене то единственный вариант именно купить ее для «вечного» использования текущей версии, это оплатить год подписки, и это уже 89,90$, либо если говорить о помесячной оплате 106,8$.
Ну на самом деле Cmake та ещё штука, использую его тоже из-за Clion. Но вот скажем статически слинковать с Qt, программу, да ещё и со static_runtime, подвиг ещё тот, динамически всё линкуется и собирается прекрасно, но вот шаг в сторону и начинается квест.
Второй пример- добавить иконку к bundle в OS X, в qmake это 2 простых строки, в cmake гораздо больше, и это все очень плохо покрыто документацией.
Вот интересно, почему они типичные паттерны использования не впиливают в свою систему. Вот это копирование DLL. Или иконка в бандле OSX. Этим же, по идее, занимаются примерно все.
Участвую в разработке довольно большого проекта с использованием qmake (QtCreator), и мечтаю о дне, когда целевая ОС обновится и будет поддерживать CMake 3+. У CMake, конечно, хватает недостатков — но вылезают они в основном при использовании нестандартных инструментов, и решаются путем написания собственных скриптов, ну или поиском на форумах. Справляться с недостатками qmake куда сложнее — в лучшем случае придется наплодить кучу pri-файлов и вручную подключать их во всех дочерних модулях, но и это не всегда помогает. Возможно, «я просто не умею его готовить», но с CMake у меня проблемы возникают реже и решаются быстрее. Правда, в крупных проектах я его пока не использую — возможно, еще передумаю.
>Если зайти на сайт, то окажется, что CLion стоит 19 баксов. 1245 рублей
Ха, а если зайти под амер. айпишником, то 90… Некрасиво как-то.
Ха, а если зайти под амер. айпишником, то 90… Некрасиво как-то.
Ок, с ИДЕ понятно, но почему виндовс и директ икс?
Боюсь не разобраться с графикой под GNU/Linux.
Более того, объем аудитории будет примерно столько же, сколько игрунов на GNU/Linux — около нуля, а нужна массовость.
Можно попробовать GNU/Linux, но только когда будет понимание вопроса.
Более того, объем аудитории будет примерно столько же, сколько игрунов на GNU/Linux — около нуля, а нужна массовость.
Можно попробовать GNU/Linux, но только когда будет понимание вопроса.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Восход Cолнца Вручную #2: По хардкору за IDE, Cmake, и моё разочарование в животных