Specifying a version on a Library in a Qt Project file.

[sbesch]

Here is the situation. I have several projects that are using the current version of a lbrary. I want these to NOT BE BROKEN" while I re-write the library for a new project. Sooner or later all projects will be updated to use the new version of the library. However, in the meantime, I want my new project to link to the newer version of the library, not the older one.

The obvious solution is to give the library a new name and/or put it into an entirely new fork, which however makes a mess of my preferred file heirarchy. It would be much nicer if I could simply specify the library version to link to with the -l option. Currently, I use the VERSION= option in the project file to set the library version, which works quite well. The problem is that qmake always links library.so to the most recent version (such as library.so.1.1.0). The older versions (such as library.so.1.0.0) are still there, but are now unlinked.

Now, the problem becomes a headache when I need to fix one of the other programs and the linker fails because it it linking to the wrong (that is new) version of the library. If I am left with putting the different versions into their own folders so that I can direct the linker to these unique folders, then so be it. I just thought it would be nice to be able to select a version using the -l option. It think that I remember being able to do this but cannot find any reference to the method I would use.

[koahnig]

I faced a similar decision. Having different libraries of some sort are providing always headaches. One way is certainly to have completely different source path' per application including all the different libs. This gives you the opportunity to fix smaller problems in the libs as well. However, the headache starts with version control systems (Git, subversion, ...).

I have started to implement different include files. These files contain the different settings (INCLUDEPATH and other stuff) per library. The idea is that you have to exchange only the name of an include and you will use a completely different library version. I think the concept shall solve the problems. However, I will when I have to use it. Unfortunately or luckily, I have not been able to use the feature yet. So far, it was always easier to recompile and relink the other applications as well.

Example of such an include file
@

----------------------------------------------------

This file is generated for use of XXXXXX libraries.

------------------------------------------------------

INPFILE = $$dirname(QMAKE_QMAKE)/inp_settings.conf
include($$INPFILE)

include (bliblaLibPath.inc)

win32:CONFIG(release, debug|release): PRE_TARGETDEPS += $$LIBSARCH/Lib1/release/libLib1.a
else:win32:CONFIG(debug, debug|release): PRE_TARGETDEPS += $$LIBSARCH/Lib1/debug/libLib1.a

win32:CONFIG(release, debug|release): LIBS += -L$$LIBSARCH/Lib1/release
else:win32:CONFIG(debug, debug|release): LIBS += -L$$LIBSARCH/Lib1/debug

message(Complete_LIBS_________: $$LIBS)

INCLUDEPATH += $$INCLUDELIBBASE/Lib1
DEPENDPATH += $$INCLUDELIBBASE/Lib1
@

Note, I am not sure, if this is really the best way to go, but I could not come up with a better one.
2nd note, beware it is time consuming.

[sbesch]

Based on the fact that there is no simpler way to specify a specific library version, and that any solution must be source versioning (git, svn, etc) compatible, I've worked out the following scheme.

First, all paths must be specified in relative fashion otherwise source versioning will fail -or at least require a horrible amount of diddling around. Then, since I already include the VERSION= directive in the project file, I can also use it in the relative path definitions. This gives me something like this in each library's project file (with the obvious proviso that the version would need to be adjusted for each version of the library):

VERSION = 1.1.0
DESTDIR = ../../libs/$$VERSION

This will put the compiled library and it's links in ~/Project/libs/1.1.0/

You do have to be careful about the number of "../" prefixes. I haven't seen this explicitly stated anywhere, but experimentation reveals that paths are relative to the directory containing the project file. So, since I have a project structure like this:

@~/Project/
libs/
1.0.0/
1.1.0/
Prog0/
app/ App.pro
Library1.0.0/ Lib.pro
Prog1/
app/App.pro
Library1.1.0/ Lib.pro@

To reach the libs directory from a Library project file I need to use "../../libs"

Then, in each application's project file, rather than just specifying a generic libs directory, I use a line like this:

LIBS = -L../../libs/1.1.0 -lmylibrary

When I decide to use a different version of the library, I only need to change the 1.1.0 to reflect the desired version and re-link the program.