Dolarun

Потому что у вас круглые скобочки в $(SOURCES) вместо фигурных - ${SOURCES} - и подстановка значения переменной не происходит

Компилятор С++ пенсионного возраста, или не настроен C++ >= С++11

-проверить, что компилятор новый (GCC 11й версии или Clang 12й)
-добавить флаг -std=c++17

Похоже cmake не может найти компилятор. Возможно надо в переменную окружения PATH добавить путь до исполняемых файлов mingw и возможно еще создать переменную окружения MINGW_HOME. Тогда cmake должен нормально найти компилятор.

Лично я не использую mingw и cmake в чистом виде. Использую msys2 с установленным туда с помощью штатного пакетного менеджера и mingw и cmake. В этом случае они отлично дружат.
Никаких проблем со сборкой именно из-за cmake не было. Можно использовать и из командной строки msys2, можно и из cmd, если добавить пути в PATH и настроить переменные окружения MSYS_HOME и MINGW_HOME.

Рекомендую использовать vcpkg (можно и conan) или же docker-контейнер с нужными зависимостями для сборки. Сам генератор систем сборки CMake.

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

При необходимости могу подробнее расписать достоинства и недостатки.

Если проект для линукса (или другого никса), то лучше ставить зависимости из стандартных репозиториев, а не включать в проект. Если библиотеки в стандартных репозиториях нет, то уже возможны варианты.

Создавать для зависимостей отдельную папку в проекте и складывать их туда - нормальная практика, если предыдущий вариант по каким-то причинам не подходит. В этом случае, если используете систему контроля версий (git), то добавляете зависимость как субмодуль, с привязкой к родному репозиторию.

header-only: nlohmann_json
компилируемая: fmt, zeromq, libuv

Стоит предупредить, что даже в приличных библиотеках в CMake-скриптах и в целом в инфраструктуре сборки может встречаться жуткая дичь (где-то - из-за необходимости поддержки старых версий CMake, где-то - из-за того что никому нет дела, пока оно работает), поэтому если собираетесь использовать эту сборочную систему, сразу читаем сюда: https://cliutils.gitlab.io/modern-cmake/ . Вот есть неплохой пример структуры проекта.

"Игровой движок" это не только "графический движок". Смысл игровых движков ка краз в том, чтобы абстрагироваться от низкоуровневых вещей. В идеале - никогда с ними не сталкиваться вообще.
Но!
Если в движке что-то не реализовано, то этого чего-то либо вобще невозможно использовать, либо нужно писать самому, возможно, на чистом OpenGL/DirectX. То есть до какого-то момента "низкие" знания не нужны, но в какой-то момент они могут очень понадобиться.
Хотя бы поверхностные знания будут плюсом - при необходимости будете понимать, куда лезть и какие знания нужно подтянуть для решения задачи.

Вопрос дурацкий, и тот кто его придумал - не самый умный человек.
Вопрос следует конкретизировать, потому что либо речь идет о выдуманном мире и выдуманной физике от человека-эзотерика, либо сформулирован так, что требует дополнения.

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

Ниже уже не архитектура, а набор отдельных элементов - транзисторы, и то, из чего они созданы - молекулы и так далее.

На молекулярном уровне люди пока не научились делать сложную архитектуру, следовательно придумать как можно было бы этим управлять, не имея даже готовой теории? Ну вот мы можем удержать электроны и нейтроны при помощи магнитного поля, когда мы удерживаем плазму. Но делать какую-то логику на уровне атомов мы не можем.
Для 2-3 нанометровых процессов уже практически приблизились поштучно к молекулам, но делается это хитрыми способами. Транзистор из парочки молекул вряд ли будет стабилен, поэтому остановятся на десятках, а дальше изыскивать принципиально другие варианты.

"Физическое устройство" довольно широкое понятие, "пробиться" ниже тяжеловато.

А "цифровой логический уровень" это вопрос организации данных. Цифровую логику можно построить на пневматических реле. Или сделать не двоичное, а пятеричное кодирование. Ниже только физический же процесс на устройстве, и состояния процесса трактуются отдельными цифрами.



Но мне кажется, вопрос следует ставить не про "уровни ниже/выше", а про альтернативы.

тут я думаю вопрос дается с упором на виртуальные машины и все подобное.
в виртуалках "ниже" виртуальных физических устройств находятся слои виртуальной машины и хостового компуктера.

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

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

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

Файлы с расширением .cpp обычно являются точками сборки модулей трансляции [?].
Характеристики связывания имеют свой эффект только между модулями трансляции. Компоновщик занимается связыванием кода и работает с результатами обработки именно модулей трансляции - объектными файлами.
Поэтому, если в одном .cpp подключить другой .cpp (исключенный из сборки иными способами), то все элементы с внутренним связыванием любого из этих .cpp будут доступны в них обоих.
Это будет справедливо и для файлов с расширением .h. Файлы .cpp обычно включают .h и все вместе своим кодом формируют модуль трансляции, в котором доступны все элементы с внутренним связыванием. Даже в коде файлов .h.
Это важно учитывать чтобы не совершать некоторых ошибок.

По существу вопроса. Все нестатические (без спецификатора static) элементы именованных пространств имен по умолчанию имеют внешнее связывание [?]. Глобальное пространство является тоже именованным (и доступно через :: без имени слева) и ровно так же наделяет все свои нестатические элементы характеристикой внешнего связывания.

В противоположность этому, абсолютно все элементы анонимных пространств имен (даже элементы вложенных именованных пространств) имеют характеристику внутреннего связывания [?].
Довольно распространенной ошибкой является определение анонимных пространств и статических элементов пространств в заголовках, после чего сразу множество модулей трансляции пополняются кодом с внутренним связыванием. Это приводит к разбуханию бинарного кода и усложнению сборки.

Отдельно хотелось бы обозначить inline.
Спецификатор inline[?] дает пометку слабого внешнего связывания для любой сущности. Что константа или глобальная переменная, что функция или метод (даже статический), помечаются как сущности с внешним связыванием, которое не нарушает ODR в случае если все определения цели связывания во всех модулях трансляции являются полностью одинаковыми. Если хоть одно определение цели связывания отличается - будет нарушение ODR.
Компоновщик подберет самое первое определение и встроит его в бинарный код. После этого компоновщик будет только проверять другие встреченные определения на предмет соответствия первому, а линковку кода будет производить только относительно первого встреченного определения.
Поэтому, если в любом именованном пространстве, в нескольких .cpp определить inline функции с одним именем и одной сигнатурой, но разными телами, то проблем со сборкой будет не избежать.

Все это можно более детально изучить в статье на хабре.