res2001

В виндовой консоли есть 2 русские кодировки cp866 и cp1251. Причем cp866 используется по умолчанию! Так же есть еще 65001 (UTF8), которая то же умеет в кирилицу. Пользователь консоли может менять кодировку по собственному усмотрению (команда chcp /?). Как правило встроенные виндовые утилиты командной строки правильно работают с любой установленной кодировкой (можете сами в этом убедиться).

Дополнительно к кодировкам самой консоли винды добавляется еще кодировка в которой написаны ваши исходники. Кодировка исходников должна быть совместима с кодировкой консоли. Если не совместима, то нужно или переключать кодировку консоли (что для консольных утилит не хорошо - это вам пользователи утилиты потом расскажут) или перекодировать вводимые/выводимые строки на лету.

Самый простой вариант решить проблему - писать исходники в cp866, тогда в консоли по умолчанию все будет выводится правильно без всяких танцев с бубном. Но если пользователь поменяет кодировку, то все опять разъедется. Кроме того использовать cp866 для исходников - не комильфо.

Лучше исходники всегда писать в UTF8 а для строк использовать wchar_t.
Тут и не только тут эта проблема уже обсуждалась не однократно. Например посмотрите эту ссылку: https://qna.habr.com/answer?answer_id=2278154#comm...
Не смотрите, что там тема по Си - проблема та же самая и решения для Си и С++ будут похожие.

Из файлов исходников, которые используются (или теоретически могут использоваться) в разных целях делаешь статическую библиотеку в рамках этого же проекта.
В зависимости от размера проекта таких промежуточных библиотек может быть много. Есть смысл сами подобные библиотеки разделять по функционалу. Например в одном тесте тестируется какой-то определенный функционал, в другом - другой функционал и т.п.
Дальше эту библиотеку(и) ставишь в зависимости для конкретных целей (исполняемый файл, тесты и т.п.)

Попробуйте в include_directories() указывать полные пути. Стандартная переменная cmake ${CMAKE_CURRENT_SOURCE_DIR} содержит путь где лежит текущий файл cmakelists.txt, ее можно использовать для генерации полного пути.
Обычно, если в проекте используется иерархия каталогов, то в каждом каталоге с исходниками лежит свой собственный cmakelists, а подключается он к нижележащему через add_subdirectory(). Собирайте в каждом каталоге свою цель (статическую библиотеку), потом эти цели указывайте в зависимостях для основной цели.

Судя по ошибке, cmake пытается использовать генератор "NMake Makefiles". nmake - это такой куцый вариант make от микрософт, идет в составе MSVS. Но MSVS у вас, похоже, не установлен, вот cmake и не может его найти.
Обычно генератор задается опцией -G при вызове cmake.
Список поддерживаемых генераторов смотрите: cmake --help
Но это не значит, что все они будут работать в вашей конфигурации, т.к. все они требуют дополнительного ПО.

Под виндой, обычно ставят MSVS или Build Tools и выбирают соответствующий генератор в cmake (или возможно cmake находит сам подходящий генератор).
Альтернативные варианты:
msys2+mingw - генератор MSYS Makefiles или MinGW Makefiles
msys2+mingw+ninja - генератор Ninja
mingw можно заменить на clang.

Смысл в том, что VS Code - это грубо говоря текстовый редактор адаптированный для написания программ.
cmake - это система сборки.
Но ничего из этого самостоятельно компилировать программы не умеет - они используют какой-то компилятор, который надо установить в систему. Какой именно - выбирать вам.
MSVS, в отличие от VS Code, это IDE со встроенным компилятором - и там уже полный фарш, думать как собрать программу не надо.
Но разобраться в этой кухне стоит, раз уж вы изучаете С/С++.

Что бы при переносе вашей программы на другой комп не терялись зависимости (библиотеки), нужно эти зависимости передавать вместе с программой явно - передавать необходимые dll файлы. Обычно для этого делают установочный пакет, куда входит все необходимое плюс скрипт установки, если требуются какие-то дополнительные действия, кроме копирования файлов.
Другой вариант - использовать статическую компиляцию с библиотеками, тогда библиотека будет входить в состав вашего исполняемого файла. Размер исполняемого файла при этом будет заметно больше.

В линуксе для динамических библиотек используется каталог (/lib; /usr/lib) отличный от каталога с исполняемыми файлами (/bin, /usr/bin), поэтому появляется возможность устанавливать библиотеки через пакеты пакетного менеджера универсально для всех программ, использующих данную библиотеку. В пакете программы просто указывается зависимости от пакетов используемых библиотек.
В винде принято все зависимости программы устанавливать в каталог с исполняемым файлом программы. И тут нет какого-то общепринятого механизма делать как линуксе. Хотя никто не запрещает вам делать свой собственный софт с подобным механизмом, но сам механизм вы должны придумать и поддерживать самостоятельно в своем софте и кроме ваших программ никто больше использовать этот механизм не будет.

В cmake есть еще вариант поиска пакетов с помощью pkg-config: https://cmake.org/cmake/help/latest/module/FindPkg...

На счет имени таргета посмотрите тут: https://stackoverflow.com/questions/31038963/how-d...
С каталогом, ну я бы в проекте сделал подкаталог MyDir и в нем свой cmakelists.txt с описанием таргета для библиотеки. Библиотека будет собираться в своем подкаталоге. В корневой cmakelists.txt включать подкаталог с помощью add_subdirectory(MyDir)

Нельзя превратить эту команду в команду cmake.
Вам нужно написать файл cmakelists.txt, который положить в папку с проектом. Там описать проект, цели, подключаемые библиотеки, опции компилятор и т.п.

Сборка с помощью cmake происходит типовыми командами практически одинаковыми для любого cmake проекта. Находясь в каталоге сборки (любой пустой каталог):

cmake <каталог с проектом> -G <generator type>
cmake --build .

generator type - зависит от того с помощью чего вы планируете осуществлять сборку. Обычно в линукс это "Unix Makefiles" в винде например "Visual Studio 15 2017". Весь список поддерживаемых генераторов можно увидеть с помощью cmake --help

Я обычно библиотеки подключаю, используя pkg_check_modules.
Эта функция ищет и динамические и статические библиотеки, используя pkg-config.
Для статических библиотек возвращается свой набор переменных с префиксом <PREFIX>_STATIC. Для подключения статической библиотеки используйте эти переменные.

Нужно добавить в INCLUDES опцию -I с путем к папке, где содержится Machinarium/Filesystem/Utils.hpp

Отлаживать библиотеку логичнее специально написанными для этого тестами. В этом случае библиотека будет представлять самостоятельный продукт. Ее можно будет устанавливать клиентам отдельно. А в основном продукте использовать find_package для поиска библиотеки.

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