Как добавить cmake в path в windows

• Программирование

В предыдущей статье имел наглость использовать CLion в качестве IDE. И тут же прибежал человек с вопросом: ой, проприетарная платная поделка, продался, зажрался, итп. Справедливости ради, на Хабре такой комментарий был всего один, но в реальности их тысячи. Например, крайний действующий аккаунт на ЛОРе, у меня зарегистрирован с 2010 года, и в почти каждой дискуссии с участием какого-то несвободного софта начинается этот ад. Понятно что никому я ничего не докажу, но редким бредущим мимо может помочь.

Статья условно делится на две части: социально-мотивационная и техническая (как собирать CMake в Windows под различными IDE).

Откуда всё пошло

В основу статьи лёг вот этот комментарий из прошлой статьи: «Если подкаст для начинающих и непрофессионалов, то почему не учли лицензию IDE :(» и далее по тексту.

Статья сделана по результатам стрима на Твиче и вашего фидбека на нём. Запись есть на YouTube. Эта статья — не расшифровка подкаста, а продукт его осмысления.

Исходный посыл

Вначале, давайте проверим валидность исходного предположения: софт — это дорого. Если зайти на сайт, то окажется, что CLion стоит 8.90 баксов в месяц. 580 рублей. Понятно, что для человека, который не зарабатывает программированием на жизнь — это иногда может показать приличной суммой, которую можно потратить на что-нибудь более полезное. Купить поесть, например.

Для профессионала всё совсем по-другому, но давайте вот оставим эту тему. Журналист отличается от работника отдела маркетинга компании-производителя софта или игры тем, что он не продвигает политику Партии, не делает шаги для продвижения продукта. Он говорит как есть. Как это всё на самом деле, как журналист по-настоящему видит вопрос. То же самое и с настоящими евангелистами.

Сущность явлений, и лет вереница,
Лица друзей, и маски врагов,
Ясно видны и не могут укрыться
От взора поэта — владельца веков.

Свет дальних звезд и начало рассвета,
Жизни секреты и тайны любви,
В миг вдохновения солнцем согретый —
Все отражается в душах поэта —
В зеркале мира…

(с) Константин Никольский, «Зеркало Мира»

Если действиетльно интересно, как CLion увеличивает ваш доход — вы найдете к кому обратиться, а мы тут о другом.

Типология

Вместо этого рассмотрим группы людей, которых максимально бомбит от закрытого софта.

Как вы уже поняли, я нифига не социолог, и имею только ту типологию, которая выработалась в жаре форумных разборок. Она имеет только то преимущество, что отнести человека к какой-то группе можно практически не включая мозг, посмотрев на первые два комментария.

Итак, люди бывают:

• Борцы за свободу и опенсорц
• Честно заблуждающиеся
• Животные

Варианта неправоты автора предлагаю не рассматривать. Я — это другое дело.

Борцы за свободу и опенсорц

Самые чистые и светлые — это борцы за опенсорц. Я и сам из тех, кто услышав слово «Linux» постоянно поправляет, «не Linux, а GNU/Linux». Проблема в том, что реальный мир ни разу не чёрно-белый. У нас есть некое количество свободы, и это — ресурс, который в случае необходимости можно использовать. Как пошутил (или нет) кто-то из менеджмента Mozilla, «зачем нам кредит доверия, если мы не будем его тратить?».

Пример: был такой человек, Мигель де Иказа. Он сделал Gnome и приложил руку к формированию дестопного GNU/Linux таким, как мы его знаем. А потом его выпихали из сообщества, а Столлман назвал его «предателем свободы»:

«Miguel de Icaza, по существу — предатель Free Software community. <…> Проект нацелен на обустройство функционирования якобы „опенсорсных“ программ на платформе Windows; тем самым бесценное время разработчиков уводится от свободных платформ»

И где теперь Мигель? Он и его команда работают бок о бок с одним из величайших проектов последних лет — переносу .NET на GNU/Linux под пермиссивными лицензиями. Он верно потратил своё время.

На стриме я убил не менее двадцати минут на то, чтобы запинать CMake под Visual Studio Code. Не получилось. А в бесплатной, но несвободной Visual Studio, получилось с первого раза. Это именно то, что мы так часто получаем при попытках использовать свободный софт: в опенсорце, по понятным причинам, нет времени продумывать end-to-end сценарии и заботиться о продукте целиком. Спасибо разработчикам уже за то, что сделали хоть что-то. Но для нас как для пользователей всё равно остаётся морально-этический выбор: либо выбрать свободу и потратить на запинывание свободного софта много времени, или напротив — потратить нашу свободу на покупку времени, которое можно потом пустить на какие-то добрые дела.

Поскольку этот вопрос выходит за рамки решаемости техническими вопросами, здесь и закончим. По-настоящему идейный человек верен своей идее.

Животные

О, а вот от этой категории меня бомбит.

«Специфическими особенностями человека, отличающими его от других животных, являются прямохождение, высокоразвитый головной мозг, мышление и членораздельная речь. Человек изучает и изменяет себя и окружающий мир, создаёт культуру и собственную историю.» (с) Википедия.

К сожалению, в разговоре об IDE зачастую оказывается, что собеседник не способен к самостоятельному мышлению, вместо членораздельной речи мычит «а мне и так норм» и жрёт что дают. Из-за прямохождения его легко спутать с человеком, но не ошибитесь.

На этих существах ездят все, кому ни попадя. В играх им продают лутбоксы и DLC с ностальгической музыкой. В редакторах их сажают на разные анально оккупированные штуки, имеющие целью привязать пациента к конкретной среде, экосистеме, и так завендорлочть, что никакого феназепама не нужно. Они всё съедят. «А мне и так норм.»

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

Например, помните манифест, который недавно выложил Никитонский (точней, его перевод на Хабр): Моё разочарование в софте? Как у меня от него бомбит. Искренне надеюсь, что Никитонский это всё писал чтобы знатно потролить, а не на самом деле.

Глядите какие там тезисы:

• Всё невыносимо медленно — современный телефон мощней компов, которые отправляли людей на Луну;
• Всё ОГРОМНОЕ — Андроид весит 6 гигабайт;
• Всё гниёт — старые девайсы не работают или работают плохо;
• В программировании хаос — посмотрите на графы зависимостей в npm и left-pad.

Троллинг троллингом, а кому-то может быть невдомёк, что размер исходников «что привели человека на Луну», то есть Аполлона-11, такой, что автор вряд ли бы захотел их читать.

Что современные операционки определяют любое оборудование и имеют в себе всё на любой случай жизни. Что тормознутость девайсов привела к чудесной ситуации, когда мерсссские капиталисссссты почеаслись и разивили железо до современного уровня, благодаря чему у нас в кармане и лежит мегадевайс на все случаи жизни. Даже полотенца не надо, оно есть в Google Play. Упомянутый npm позволяет в час обычному человеку писать невообразимой сложности вещи, которые раньше заняли бы годы.

И вот всем этим товарищам, которые «жрём что дают», внезапно в голову начинают прилетать мега-идеи из списка выше. Давайте распространим на IDE:

• У приложений на Electron (Visual Studio Code, Atom) буковки появляются на экране слишком медленно, то ли дело vim или emacs;
• Eclipse IDE тормозит;
• Вообще, тормозит Java — вместе со всем, что на ней написано, включая NetBeans, IDEA и Clion;
• Любые IDE тормозят жрут проц просто так;
• Проприетарщина — зло;
• Список можно продолжать.

Этого списка уже хватит, чтобы капитально съехать крышей. Не верьте всякой фигне. Если vim лучше Eclipse (или наоборот) в некоторых кейсах, то это точно не потому, что вимеров соседи облучают микроволновкой, а эклипсеров ночью похищают пришельцы.

К сожалению, в результате долгих сетевых диванных войн было в точности установлено: диалог тут можно не вести. Человеку — человеческое, а животному — животное. Так устроена жизнь. Вероятность, что кто-то прочитает эту статью и одумается крайне мала, immolate improved.

Честно заблуждающиеся

Теперь мы закончили с крайностями: особо умными из секты Столлмана с одной стороны спектра, и не очень умными животными с другой, давайте поговорим об обычных людях.

Первое заблуждение в том, что мы каким-то образом прибиты гвоздями к IDE. Это пошло с тех времён, когда люди использовали какие-то Delphi 7 и древние версии Microsoft Visual Studio. Говорят, в новой Вижуалке всё стало хорошо с проектными файлами. Привет-привет, сейчас на дворе 2018 год, рабства больше нет.

Чтобы избавиться от рабства нам свыше дан CMake: тулсет из кроссплатформенных опенсорсных утилит, который позволяет собирать, тестировать и паковать приложения.

Это всё ещё ничего не говорит новичку и руки тянутся к IDE. Всё это от страха и непонимания происходящего. Я сам родом из джавы, и поэтому хорошо знаю, как расширяются глаза человека, в первый раз увидившего pom.xml.

Давайте разберёмся, из чего состоит созданный в прошлый раз проект, и как его построить во всевозможных разных IDE.

Состав файлов:

• CMakeLists.txt
• main.cpp
• shaders.shader

Шейдер у нас компилируется прямо в рантайме, функцией D3DCompile. Работает D3DCompiler из DirectX SDK (который теперь Windows SDK). Никакого IDE для его сборки не нужно.

main.cpp — это единственный файл, который надо собрать. И собирается он с помощью информации, которая целиком и полностью находится в CMakeLists.txt.

В обратную сторону: есть CMakeLists.txt, который говорит нам, что именно мы собираемся скомпилировать. В нём прописана сборка main.cpp. Этого хватает, чтобы скомпилировать проект. После компиляции получается exe-файл, который после запуска собирает и шейдер, и показывает его на экране. Всё предельно просто, IDE в этой цепочке не участвует и может быть любым.

IDE не обязательна. Вообще. Что тут непонятного?

Сборка

Подготовительные моменты

Как всегда, подготовка занимает чуть ли не большую часть процесса. Нужно уяснить несколько вещей.

Предполагается, что всё делается на основе Msys2, который мы устанавливали в прошлый раз. Если это не так, расхлебывать придется самостоятельно

Как установить CMake и Ninja

Чтобы мочь что-то собрать, необходимо установить CMake, если вы это ещё не сделали.

• Качаем с сайта: https://cmake.org/download. У меня cmake-3.12.2-win64-x64;
• Распаковываем и добавляем в виндовую переменную окружения PATH путь до места, где лежит cmake.exe;
• Качаем с сайта генератор ninja самой свежей версии;
• Распаковываем и тоже кладём куда-нибудь в PATH.

Как редактировать PATH, чтобы не поехать кукухой

Первый способ всем известен: win+pause -> Advanced system settings -> Advanced -> Environment variables. К сожалению, даже в Windows 10, в которой добавили редактор переменной PATH, это всё ещё не очень удобно.

Если вы часто пердолитесь с PATH, использование стандартного окна редактирования очень действует на нервы. Советую использовать Rapid Environment Editor — он бесплатный и сильно экономит нервы.

Как подключать DLL из MinGW в режиме разработки

Чотбы приложуха запустилась, нужны dll файлы как минимум из mingw64bin.

К сожалению, я так и не смог найти действительно удобного решения для подбрасывания библиотек из MinGW в PATH. Если какой-то мудрец в комментариях можект рассказать, буду премного благодарен.

Сейчас самым простым кажется подкладываение bin-директории MinGW прямо на первое место в PATH. (В случае Visual Studio, можно и просто набросать библиотек в каталог сборки.) К сожалению, у этого способа есть огромный минус: часть софта в Windows начинает отваливаться сразу же после модификации PATH. Например, у меня перестал запускаться Overwatch, а это совершенно фатальная штука.

Если вы так же, как и я, живёте в компьютере, а не только включаете его в рабочие часы, предлагается следующая схема: перед началом программирования добавлять MinGW в PATH, а после — убирать. Для облегчения процесса нужно сделать два батника, которые можно запускать двойным щелчком:

before.bat:

setx path "Z:msys64mingw64bin;%path%"

after.bat:

setx PATH "%PATH:Z:msys64mingw64bin;=%"

Как подключать DLL в режиме «тестового релиза»

Ясно, что предыдущий способ работает только пока mingw64bin находится в PATH, то есть только на компьютере разработчика. Да и там даже, не всегда хочется уродовать PATH. Если же это запустит обычный человек (или мы сами после запуска after.bat), то произойдет нечто вроде:

Самый простой способ решить эту проблему — подложить нужные dll рядом с исполняемым файлом. Но для этого нужно узнать, какие dll используются!

У нас уже есть для этого некие утилиты производства Microsoft.

• Посмотреть полный список работающего приложения можно было бы с помощью ListDLLs, но оно не показывает то, что ещё не загружено.
• Если сделать Tools -> Visual Studio Command Prompt, dumpbin /dependents "Z:gamebuildMingw64-Debugsrc.exe", то оно покажет только dll самого первого уровня. Иначе говоря, если докинуть только то, что подсказывает dumpbin, то после запуска всё ещё будут ошибки — просто они будут про другие DLLки.

Чтобы побегать по зависимостям в глубину, есть вот такой скрипт, который можно выполнять прямо из командной строки (msys2, cygwin, итп — достаточно чтобы там внутри был установлен python2/3 и objdump).

• Качаете скрипт mingw-bundledlls,
• Кладёте рядом с экзешником,
• В текстовом редакторе в массив blacklist = [ добавляете наши кусочки DirectX: d3d10.dll, d3d11.dll, d3dcompiler_43.dll,
• chmod 755 ./mingw-bundledlls,
• Чтобы посмотреть использованные dll: ./mingw-bundledlls ./src.exe (ну, любой экзешник, который вам более интересен),
• Чтобы автоматически скопировать и положить рядом: ./mingw-bundledlls --copy ./src.exe
• PROFIT: экзешник запускается и просто так, двойным щелчком по exe-файлу, и из Visual Studio.

Есть ещё разные хитрые способы подрядить CMake сам копировать dll, но если начинать углубляться в вопросы дистрибуции, то так можно это статью вообще никогда не закончить.

Сборка вручную

• before.bat
• Пуск -> Выполнить -> cmd.exe
• cd /d z://game/src
• cmake -G "Ninja" -D EXECUTABLE_OUTPUT_PATH="bin" -D CMAKE_CXX_COMPILER="Z:/msys64/mingw64/bin/g++.exe" -D CMAKE_C_COMPILER="Z:/msys64/mingw64/bin/gcc.exe" .
• ninja
• Запускаете сгенерированный в bin файл сразу, или подкладываете dll по инструкции выше и выполняете after.bat

Мы докзали, что не привязаны к IDE вообще.

Сборка в Visual Studio

Но всё-таки, разрабатывать без IDE — не дело. В прошлый раз мы уже собрали тестовое приложение с помощью CLion. Но это ведь платная проприетарщина и зашквар, верно? Забудем. Теперь только свободка.

В Visual Studio последовательность необходимых действий супер простая.

• before.bat
• Запустить Visual Studio;
• File -> Open -> CMake;
• Выбрать CMakeLists.txt;
• Вижуалка некоторое время думает и отображает проект;
• Главное меню -> Cache -> Generate -> имя проекта;
• Смотрим на Output и исправляем ошибки (например, у меня ругалось на версию CMake, пришлось опустить до 3.11 вместо 3.12);
• Главное меню -> CMake -> Change CMake Settings (выбираем MinGW64-Debug);
• В проекте автогенерируется файл CMakeSettings.json. Указываем там путь до MinGW (у меня это в предыдущем видео был «Z:msys64mingw64»), сохраняем файл;
• Главное меню -> Cache -> Generate -> CMakeLists.txt;
• Главное меню -> Cache -> Generate -> имя проекта;
• Если всё правильно сделали, в меню Select a valid startup item (рядом с зеленой стрелкой запуска приложения) появится пункт с именем проекта;
• Запускаем.

Как и в случае с консолью, можно запустить прямо так (помня, что MinGW находится в PATH), либо выполнить after.bat и подложить необходимые DLL по инструкции. DLL нужно класть прямо в каталог, куда собирается приложение. Его можно указать в параметре buildRoot в файле CMakeSettings.json.

Итак, господа, самое главное: из Visual Studio всё отлично компилируется и запускается. Мы докзали, что не привязаны к коммерческой IDE.

Сборка в Visual Studio Code

К сожалению, Visual Studio всё ещё остаётся несвободным закрытым ПО. Нужно перейти к чему-то более свободному, и это Visual Studio Code.

Вначале забавный майндфак. Если запустить VSCode на мониторе с большим масштабированием (я дома сижу за телевизором, например), то интерфейс VSCode превратится в кашу. Чтобы этого не происходило, нужно запускать его с ключом --force-device-scale-factor (сделать ярлычок на рабочий стол, или что-то такое).

К сожалению, менеджмент PATH для VSCode я так и не осилил, поэтому единственный способ запуска — это модификация PATH с помощью before.bat и ещё один хак, который я опишу ниже.

Дальше надо настроить VSCode.

• Устанавливаем CMake Tools: View -> Extensions -> в поиск вписать «CMake Tools», нажать install напротив пакета, который сделал автор vector-of-bool.
• View -> Explorer -> Open Folder (выибраем директорию с нашим проектом);
• Command Palette (CP, шорткат Ctrl+P) -> «> CMake: Scan for Kits»;
• Выбрать наш «GCC 8.2.0», пусть до которого ведёт в правильное место, где установлен msys2 или что вы там используете;
• File > Preferences > Settings;
• Перейти на вкладку User Settings;
• Щелкнуть по трём точкам в верхнем правом углу панели, и из меню выбрать «Open settings.json»;
• Добавить следующие опции:

"cmake.configureOnOpen": true,
    "terminal.integrated.shell.windows": "D:/msys64/usr/bin/bash.exe",
    "terminal.integrated.shellArgs.windows": [
        "-i"
    ],
    "terminal.integrated.env.windows": {
        "PATH": "/mingw64/bin;/usr/local/bin;/usr/bin;/bin;Z:/msys64/bin/;Z:/msys64/usr/local/bin;Z:/msys64/usr/bin;Z:/msys64/bin;Z:/msys64/mingw64/bin/;%PATH%"
    },
    "cmake.buildDirectory": "${workspaceRoot}/build/${buildType}",
    "cmake.clearOutputBeforeBuild": true,
    "cmake.generator": "Ninja",    
    "cmake.cmakePath": "C:\my\opt\cmake-3.12.2-win64-x64\cmake-3.12.2-win64-x64\bin\cmake.exe",
    "cmake.mingwSearchDirs": [
        "Z:/msys64/mingw64",
    ],
    "cmake.preferredGenerators": [
        "Ninja"
    ],
    "cmake.loggingLevel": "debug"

• Сборка должна произойти автоматически, и билд сложится в директорию build. Если этого не произошло, нужно мышкой клацнуть по кнопке Build с шестерёнкой в статусной строке.

Понятно, что там нужно напрямую указать путь до mingw и cmake. «Но у меня же PATH!» Просто укажите, пожалуйста, это решит целый комплекс проблем.

Есть, впрочем, один эксклюзивный способ не поганить себе PATH.

• "cmake.generator": "MSYS Makefiles"
• "cmake.preferredGenerators": [ "MSYS Makefiles"]
• Проверьте что MinGW нет в PATH (after.bat);
• Проверьте что удалили директорию build в проекте.
• Запустите консоль Msys2;
• export PATH=/z/msys64/mingw64/bin;$PATH (можно потом будет вписать в какой-нибудь "~/.bashrc")
• Из неё запустите VSCode, например так: "C:UsersolegchirAppDataLocalProgramsMicrosoft VS CodeCode.exe"
• И дальше всё как раньше. Должен нормально сгенерироваться файл.
• При попытке немедленно запустить его из Проводника двойным щелчком мгновенно приведёт к ошибкам поиска DLL — это значит, что всё верно, внутри VSCode у нас действительно используется специальный PATH, а вне его — нет.

Итак, мы доказали что в свободном IDE мы тоже жить вполне себе можем.

Итоги

Резюмируя, если вы нормальный человек, то можете пользоваться CMake, MinGW и в ус не дуть. Всё свободно переносимо между IDE, всё просто работает. Мы можем в любой момент использовать любую платную, закрытую, несвободную IDE, и нам за это ничего не будет. А вот все остальные будут страдать, и поделом.

В будущих статьях будет учитываться ваше мнение. Вы можете прямо во время стрима на Твиче завать вопросы и предлагать предложения в комментариях. Будут ли вообще эти статьи — зависит от того, насколько яростно вы наяриваете стрелочку вверх под этим комментарием.

олег родился в интернете
в почтенной геймерской семье
питался лайками и в гугол
за двойки ставили его

© Александр Раевский

Step#1: download Cmake

• Download the Cmake software through this link—>
• Go to the download section
• Select option as window’s x64 zip
• After complete download extract files by using WinRAR software

Step#2: set binaries

• Open the CMake folder and locate the bin folder
• Open the bin folder and copy the path
• C:UsersMohammed AneesDesktoplibrariesCmakecmake-3.20.1-windows-x86_64cmake-3.20.1-windows-x86_64bin

Now go to this pc—>properties—>advanced system settings—> environment variables

Select the path and edit it

Don’t delete the existing path but first, add(semicolon ; ) before the path and then paste it

In some pc, you might get a different window like below in that case you no need to add( semicolon ; ) just click new and paste  the bin path

Step#3: check whether you install it right

• Win+x —>Go to Run —> type CMD—> then type the command cmake – -version

Step#3: Create CMake-GUI on desktop

• Open CMake folder—>bin—> CMake-gui—> right click—> send to desktop

Краткая инструкция по установке всех нужных для курса библиотек для Visual Studio

На Windows рекомендуется использовать

• Visual Studio Community Edition последней версии для разработки
• vcpkg для установки пакетов
• CMake для сборки некоторых библиотек

Без vcpkg каждую библиотеку придётся ставить по отдельности. Пакетный менеджер vcpkg автоматизирует скачивание и сборку библиотек на машине разработчика.

Установка CMake

Для сборки примеров потребуется CMake. Свои работы можно делать без CMake.

• Скачайте Cmake с официального сайта
• При установке не забудьте поменять опцию, чтобы путь к CMake был добавлен в переменную PATH

• Переменные окружения, такие как PATH, передаются приложению при старте. Если вы поменяли переменную PATH, изменения вступят в силу после перезапуска программ.

Установка и использование vcpkg

Источник: blogs.msdn.microsoft.com/vcblog/2016/09/19/vcpkg-a-tool-to-acquire-and-build-c-open-source-libraries-on-windows

Пакетный менеджер vcpkg распространяется в исходниках и собирается на машине разработчика. Для сборки потребуется установленная Visual Studio с инструментами C++ разработчика.

Порядок установки описан в консольных командах:

:: Клонируем репозиторий vcpkg (ветка master)
git clone https://github.com/Microsoft/vcpkg

:: Переходим в каталог клона репозитория
cd vcpkg

:: Выполняем скрипт для сборки vcpkg
powershell -exec bypass scriptsbootstrap.ps1
:: Теперь в корне репозитория лежит vcpkg.exe, который можно вызывать
::  из каталога либо добавить в переменную окружения PATH.

:: Установка библиотеки выполняется командой install
vcpkg install sdl2:x86-windows-static sdl2:x64-windows-static

Из команды выше легко понять, что имена пакетов перечисляются по порядку, а в качестве суффикса используется так называемый “триплет”: имя_пакета:триплет.

• Имя пакета задаёт одно из множества имён доступных библиотек.
• Триплет задаёт архитектуру и режим сборки

Доступные триплеты:

arm-uwp.cmake
x64-uwp.cmake
x64-windows-static.cmake
x64-windows.cmake
x86-uwp.cmake
x86-windows-static.cmake
x86-windows.cmake

Для данного курса рекомендуются триплеты x86-windows-static для сборки 32-битной версии программы и x64-windows-static для сборки 64-битной версии. Суффикс static означает, что библиотеки будут собираться статически и вам не потребуется распространять DLL.

Вместо явного указания триплета для каждой библиотеки можно разом указать триплет для всех:

vcpkg --triplet x86-windows-static sdl2 sdl2-image

Последняя, но крайне важная деталь: включите автоматическую интеграцию пакетов vcpkg во все проекты Visual C++:

:: Включаем интеграцию во все проекты Visual C++ в системе.
:: При первом запуске нужны права администратора.
vcpkg integrate install

:: Удаляем интеграцию - если она вам помешала.
vcpkg integrate remove

Установка пакетов для курса

Мы используем следующие библиотеки:

• sdl2, sdl2-image, sdl2-mixer, sdl2-ttf в целях абстрагирования от операционной системы для создания окон, растеризации текстовых надписей, загрузки изображений с диска, загрузки и проигрывания звуковых файлов
• glbinding для прозрачного подключения нужной версии API OpenGL без необходимости вручную работать с механизмом расширений OpenGL
• assimp3 для загрузки 3D моделей из множества форматов файлов
• anax для построения архитектуры программы на принципах Component-Entity-System
• bullet3 для расчёта столкновений в 3D пространстве
• glm для работы с линейной алгеброй в рамках задач 3D графики
• nlohmann-json для загрузки JSON
• tinyxml2 для загрузки XML

Команда для установки 32-битных версий библиотек из исходников может выполняться долго, т.к. сборка занимает длительное время:

vcpkg --triplet x86-windows-static sdl2 sdl2-image sdl2-mixer sdl2-ttf glbinding assimp anax bullet3 glm nlohmann-json tinyxml2

Настройка gitignore для своих проектов

В Visual Studio управление настройками сборки производится в графическом режиме в окне настроек проекта, хотя сами настройки сохраняются в XML определённой схемы в файле *.vcxproj. Виртуальные папки (фильтры), по которым разложены файлы проекта, сохраняются в файле *.vcxproj.filters. Настройки проекта из раздела Debugging, а также некоторые неявные пользовательские настройки сохраняются в *.vcxproj.user. Есть общепринятые правила:

• Файлы *.vcxproj необходимы и достаточны для сборки проекта, их следует держать под контролем версий Git, а настройки проекта изменять аккуратно
• Файлы *.vcxproj.filters не нужны для сборки, но хранят фильтры файлов, их тоже следует держать под контролем версий Git
• Файлы *.vcxproj.user хранят специфичные для компьютера настройки, их не следует держать в Git
• Файлы *.sln хранят списки проектов и информацию о сборке всего списка проектов в разных конфигурациях. Их следует держать в Git.

Вы можете взять готовый шаблон файла .gitignore из репозитория github.com/github/gitignore. После добавления файла .gitignore в корень своего репозитория достаточно сделать commit, добавляющий этот файл.