Лучшая практика для хранения внешних библиотек в Windows Qt Project

Question

Я работаю над проектом в Qt, который использует несколько внешних библиотек, и мне интересно, есть ли общий способ сделать источник несколько переносимым между разными машинами.

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

Чтобы дать вам пример, вот часть беспорядок мой .pro файл в данный момент:

LIBS += -L"c:/Program Files/Microsoft SDKs/Kinect/v1.7/lib/x86/" -lKinect10 

win32 { 
INCLUDEPATH += "c:/Program Files/Microsoft SDKs/Kinect/v1.7/inc" 
DEPENDPATH += "c:/Program Files/Microsoft SDKs/Kinect/v1.7/inc" 
} 

LIBS += -ladvapi32 \ 
-lgdi32 

INCLUDEPATH += "$$PWD/../../../../../Libraries/PCL 1.6.0/include/pcl-1.6" 
DEPENDPATH += "$$PWD/../../../../../Libraries/PCL 1.6.0/include/pcl-1.6" 

INCLUDEPATH += "C:/Libraries/PCL 1.6.0/3rdParty/Boost/include" 
DEPENDPATH += "C:/Libraries/PCL 1.6.0/3rdParty/Boost/include" 

LIBS += -L"$$PWD/../../../../../Libraries/PCL 1.6.0/3rdParty/Boost/lib/" -llibboost_date_time-vc100-mt-gd-1_49 

LIBS += -L"$$PWD/../../../../../Libraries/PCL 1.6.0/lib/" -lpcl_visualization_debug 

LIBS += -L"$$PWD/../../../../../Libraries/opencv/build/x86/vc10/lib/" -lopencv_core245 

INCLUDEPATH += "$$PWD/../../../../../Libraries/opencv/include" 
DEPENDPATH += "$$PWD/../../../../../Libraries/opencv/include" 

Какой самый лучший способ организовать это?

Answer 1

Я бы порекомендовал вам иметь папку «3rdparty» в вашем проекте, как Qt does that internal in its repository. Таким образом, вы можете правильно настроить пути, которые будут одинаковыми на каждой машине.

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

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

Один «термин», который вы, возможно, ищете, является «внешним», который существует в мире svn, но вы можете рассматривать это как репозиторий git в другом репозитории git. Дело в том, что вы подключаете общий «репозиторий» для совместного использования проектов, имеющих зависимость от него.

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

Эти вещи довольно распространены в моем опыте в мире с открытым исходным кодом, а также в собственности.