Поиск файлов ресурсов при разработке & amp; при установке (C ++ / Python, в основном в Linux)

Мой проект имеет глобальный каталог активов (/usr/share/openage), который содержит различные файлы (графика, тексты, …) и каталог ресурсов для конкретного пользователя (~/.openage), который позволяет пользователю перезаписывать некоторые глобальные активы / добавлять свои собственные.

Насколько я понимаю, при сборке вы передаете префикс установки в систему сборки (например, ./configure --install-prefix=/usr), который, в свою очередь, сгенерирует файл (например, configure.h) который делает префикс установки доступным для кода (например, #define INSTALL_PREFIX="/usr"). Затем код будет искать свои активы в INSTALL_PREFIX "share/openage", Все идет нормально.

Однако, когда проект еще не установлен (что в 99,9% случаев для меня как разработчика), каталог /usr/share/openage очевидно, еще не существует; вместо этого я хотел бы использовать ./assets в текущем каталоге. Еще хуже, если установленный каталог существует (например, из независимой, более ранней установки), данные могут быть несовместимы с текущей версией разработчика.

Точно так же, если выполняется установленный проект, я бы хотел, чтобы он использовал домашний каталог пользователя (~/.openage) в качестве пользовательского каталога ресурсов, находясь в «devmode», он должен использовать каталог типа «./userassets».

Это становится еще хуже, если думать о не POSIX платформах. В Windows INSTALL_PREFIX бесполезен, так как программы могут быть установлены в основном где угодно (программы просто используют текущий рабочий каталог или как каталог ресурсов?), и я не имею ни малейшего представления, как Mac справляется с этим.

Итак, мой вопрос: Есть ли общепринятый «лучший способ сделать это»? Конечно, сотни проектов (в основном каждый отдельный проект, имеющий каталог ресурсов) решали эту проблему так или иначе.

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

• Ищу файл openage_version, который существует только в исходном каталоге, в cwd, Если он существует, предположим, что проект в настоящее время удален.
  • Проблема: даже в «режиме разработки», cwd не всегда может быть корневым каталогом проекта.
• Проверяем ли readlink("/proc/self/exe") начинается с INSTALL_PREFIX
  • Проблема: для платформы
  • Проблема: теоретически корневой каталог проекта может находиться в /usr/myweirdhomedirectory/git/openage
• Заставить разработчиков указать аргумент --not-installedили установить переменную среды, OPENAGE_INSTALLED=0
  • Проблема: неудобная
  • Проблема: если забыть указать аргумент, это приведет к путанице при использовании неправильного каталога ресурсов
• Во время разработки звоните ./configure с другим INSTALL_PREFIX
  • Проблема: когда проект собран для установки, рекомендуется make test будет запускать тесты, пока проект не установлен
• Сочетание первых двух вариантов: проверка на dirname(readlink("proc/self/exe")) + "/openage_version"
  • Проблема: еще больше зависит от платформы
  • Это кажется самым надежным вариантом на данный момент