Best practice for storing external libraries on Windows Qt Project

Question

I'm working on a project in Qt which uses a number of external libraries and I wonder if there is a common way of making the source somewhat portable between different machines.

At the moment I have various libraries added to the project through Qt Creator (Add library...), which uses relative paths in the .pro file. This obviously not only stops working as soon as I move the project, but also doesn't work on other machines if any of the library paths change. Using absolute paths solves only part of the problem as I still need to make sure each library on each machine is exactly under the same path.

To give you an example here's a part of a mess my .pro file is at the moment:

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"

What's the best way to organise this?

Answer 1

I would recommend to have a "3rdparty" folder within your project just like Qt does that internal in its repository. This way, you could set up the paths properly that will be the same on each machine.

If it is necessary to have binaries for different architectures, etc, then I would suggest to even import the code. You could then just build them on the fly for the target system. It would take a bit more time than using prebuilt libraries, but that is the price for that for flexible.

If you need to get common libraries working across several projects, you could always use a dedicated repository for this, and have a policy where it has to be checked out.

One "term" that you may be looking for is "externals" which exists in the svn world, but you could consider that as a git repository within another git repository, too. The point is that, you plug the common "repository" in to share across the projects having a dependency on it.

You could always have a setup script as well that just sets up the paths correctly for the people without much flexibility. I saw this a lot in big companies with corporate environments where they tried to aim consistency for the price of less flexibility.

These things are fairly common in my experience in the open source world as well proprietary.