Хорошая практика для реализации каталогов ресурсов
Я не уверен, является ли это слишком общим, поэтому, если это так, я скажу, что я использую qmake на Linux, но я бы хотел иметь возможность переключаться с Linux на Windows с моим проектом, когда мне это нужно, а также, возможно, другие ПК.
Чтобы сделать это, я хотел бы знать, как некоторые из программистов, которые здесь работают, использовали каталоги ресурсов без определения абсолютного пути. С Qt похоже, что рабочий каталог времени выполнения строить каталог приложения, а не исходный каталог.
В идеале, я думаю, что лучшим решением было бы как-то получить каталог Resource, поскольку он находится в исходном каталоге, и скопировать его в относительный каталог сборки (т. Е. Debug или Release, в зависимости от стадии разработки), чтобы приложение могло получить к нему доступ через время выполнения.
Однако это может привести к некоторым осложнениям (по крайней мере, я так думаю).
В любом случае, что было бы хорошим решением для этого?
Решение
Если вы используете Qt. Я бы предложил использовать процесс развертывания.
http://doc.qt.digia.com/qtcreator/creator-building-running.html
По сути, вам просто нужно объявить, какие каталоги нужно скопировать.
Создатель qt скопирует эти каталоги в build dir (release / debug) после завершения процесса сборки. Затем вы просто запускаете исполняемый файл.
Вот один из примеров.
https://github.com/longwei/incubator-cordova-qt.
в профессиональном файле
wwwDir.source = www
xmlDir.source = xml
qmlDir.source = qml
DEPLOYMENTFOLDERS = wwwDir xmlDir qmlDir
второй
include(deployment.pri)
qtcAddDeployment()
тогда это сделано.
Другие решения
Непонятно, чего именно вы пытаетесь достичь, но, возможно, простым решением было бы, чтобы скрипты сборки пропустили необходимый путь через определение компиляции (-D с gcc). Затем, в зависимости от того, будет ли его сборка Debug, Release и т. Д., Определение будет установлено соответственно, тогда соответствующий бинарный файл будет иметь правильный путь.
Как примечание, я некоторое время пробовал qmake, но обнаружил, что SCons гораздо более универсален.