res2001

Вообще обычно бибилотеки ставятся отдельно в систему (для линукс) с помощью стандартного пакетного менеджера.

Если вашей библиотеки в пакетном менеджере нет, то можно и собирать из исходников.
В этом случае можно и просто "сувать" все файлы в add_executable. Никто ж вам это запретить не может.
Но обычно проще, лучше и универсальней для сторонних библиотек создавать свои собственные цели с помощью add_library и уже их подключать к основной цели с помощью target_link_libraries. Библиотеку можно делать как динамическую, так и статическую.
Если проект достаточно развесистый и содержит например тесты и/или несколько исполняемых файлов, то вообще можно в каждом каталоге проекта создавать отдельную статическую библиотеку. На больших проектах это часто может сэкономить время на компиляции, за счет того что в несколько конечных целей будут линковаться уже готовые библиотеки, а не пересобираться из исходников каждый раз.

В команде call, на соклько помню нужно указывать имя файла с расширением. Она вызывает другой внешний батник. Проверить сейчас поведение команды без указания расширения не могу.
В любом случае, если тут должен вызваться activate.bat, то надо его смотреть то же.

По остальным командам вообще не чему тормозить, кроме, конечно питоновского скрипта.
Ну и не забывайте, что в конце стоит команда pause - она ждет нажатия any key пользователем. Ждать может до посинения.

Вполне востребованная библиотека.
Но учить не стоит. Стоит знать, какие возможности она предоставляет и как ее исопльзовать в своем проекте. Сделать пример с какими-нибудь достаточно сложными компонентами буста, например asio.

Когда вы передаете в функцию указатель на объект (на что угодно), это значит, что вы можете в функции изменять этот объект и все изменения будут видны вызывающему коду.
Если вам надо что бы вызывающий код увидел новый указатель, то передайте в функцию указатель на указатель:

int next_edge(edge_t **out_edge)
{
  edge_t * tmp = malloc(sizeof(edge_t));
  if(tmp)
  {
     *out_edge = tmp;
     return 1;
  }
  return 0;
}

Но обычно проще в таком случае возвращать указатель в возвращаемом значении. Вызывающий код может сравнить возвращенное значение с NULL для выяснения того вернула функция нормальный указатель или произошла ошибка. Так делает, например, функция malloc().

Что касается ImageMemoryCache: в методе get вы возвращаете ссылку на элемент мапы. Блокировка с мапы снимается при выходе из get, но вызывающий код имеет ссылку и может с этим объектом делать все что угодно.
Параллельно вы можете вызвать clear, который удалит элемент на который осталась ссылка в другом потоке.

По уму вы должны блокировать мапу до тех пор пока жива любая ссылка на содержимое мапы.
Второй вариант - создавать в get копии объектов из мапы и возвращать их. При этом изменение этого нового объекта никак не повлияет на объект в мапе. Ну тут можно что-нибудь придумать, сделать какой-то прокси объект и т.п.
Третий вариант - каждый объект в мапе защищать своим мьютексом.

У меня был некоторый опыт с uboot, правда для другой ОС

Если у вас какая-то стандартная покупная плата, то возможно в uboot уже есть готовый config. Обычно производители плат в документации указывают как собрать uboot под их плату (если они поддерживают uboot), либо это можно нагуглить в интернете.
Если же плата самодельная, то берете самый близкий для вашей платы config (вы же брали за основу какой-то референс дизайн платы, вот эту плату и берите за основу), переименовываете его и вносите в него соответствующие изменения.
Бывает, что вместе с config'ом требуется вносить изменения и в dts, они в uboot лежат в ./arch/<platform name>/dts. Название используемых dts лежит в переменной CONFIG_DEFAULT_DEVICE_TREE и/или в CONFIG_OF_LIST в config файле.

Config файл - это просто набор параметров, которые превращаются в набор инструкций #define при сборке.
С dts все сложнее. Там целый язык описания железа.

Для сборки uboot рекомендую следующую последовательность:
1. Заведите для сборки отдельный пустой каталог. Он будет текущим каталогом для всех дальнейших команд
2. Пусть каталог где лежит сам uboot хранится в переменной UBOOT_DIR. Архитектура процессора вашей платы (например arm) в переменной ARCH. Префикс для кросскомпилятора в CROSS (например arm-linux-gnueabihf-). Имя выбранного defconfig файла в переменной DEFCONFIG (имя указываете вместе с суффиксом _defconfig)
3. Очистка каталога сборки:

make -C $UBOOT_DIR ARCH=$ARCH CROSS_COMPILE=$CROSS distclean

Эта команда пригодится при пересборках в случае изменения конфигурации
4. Подготовка конфигурации для сборки:

make -C $UBOOT_DIR ARCH=$ARCH CROSS_COMPILE=$CROSS $DEFCONFIG

5. Сборка: make -C $UBOOT_DIR ARCH=$ARCH CROSS_COMPILE=$CROSS

Несколько полезняшек:
1. Вы можете задавать дополнительную опцию для make: -O <путь>
Она задает каталог, в котором будет происходить сборка. Этот каталог make создаст сама. Это бывает удобно, если работаете сразу с несколькими конфигами.
2. В uboot встроен конфигуратор конфигов :) Конфигурация происходит в текстовом режиме с помощью меню, присутствуют подсказки для опций и т.п. Когда вы создали начальную конфигурацию в п.4 выдайте команду:

make -C $UBOOT_DIR ARCH=$ARCH CROSS_COMPILE=$CROSS menuconfig

Тут то же можно добавлять опцию -O для выбора каталога с конфигурацией. После исправления конфигурации, не забудьте ее сохранить.
Дальше нужно дать команду:

make -C $UBOOT_DIR ARCH=$ARCH CROSS_COMPILE=$CROSS savedefconfig

Она создаст на основе текущей конфигурации defconfig файл в каталоге сборки. Этот файл можно переименовать в <имя платы>_defconfig и подложить в каталог с конфигами uboot и в дальнейшем использоавть его для сборки.
3. В каталоге с uboot дайте комаду make help для получения списка возможных опций.
4. Обычно я собираю uboot под линукс, но та же схема вполне работает и в WSL под виндой. Набор кросс-компиляторов есть в портах (в WSL исопльзовал дистрибутив ubuntu).

Желаю удачи!

При чем тут cmd/bat?
Делайте бэкапы, и восстанавливайте файлы из бэкапов.
Обычно чем вы создаете бэкапы, тем же инструментом и восстанавливаете.
Инструментов для бэкапа/восстановления много. В т.ч. можно накропать соответствующие скрипты и на батниках, используя какой-нибудь архиватор.

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

Смотри сначала сюда: https://en.cppreference.com/w/cpp/io/basic_fstream
Потом сюда: https://en.cppreference.com/w/cpp/io/basic_filebuf/open
fstream открывает файл по умолчанию (как у тебя) в режиме in|out, а это значит, что если файла не существует, то возникает ошибка (смотри таблицу по второй ссылке). Логика такая, что если ты открываешь файл для чтения (тут не важно, что он открывается еще и для записи) без дополнительных флагов, то файл должен существовать.

В пару с ifstream, который открывает файл для чтения, существует и ofstream - он открывает файл для записи. При использовании ofstream не существующий файл будет создан (смотри таблицу по второй ссылке).

schtasks /?

Напишите команду start сразу после do.
Или можно завернуть start в круглые скобки. Открывающая круглая скобка должна быть после do в той же строке.
Т.е. for вместе с телом цикла - это одна команда для cmd и она должна быть на одной строке. Круглые скобки позволяют обойти это ограничение.