[Qt-interest] qmake: suppress version number from library name?

[Oliver.Knoll at comit.ch]

Sorry, Andreas, accidentally sent to you in private before!

On 2011-01-05 Andreas Andreas Pakulat wrote:

>> ...
>> Question: What is the proper way to suppress the version being part 
>> of the
> library name?
> 
> Why? 

Because these libraries are part of my application and shipped every time I ship the application. They are not meant to be used by anyone else (except by application plugins later on), so I have full control over them. For sure they are not "system libraries". In theory I don't even need to care about binary compatibility (except for the plugins later on, if I want to keep plugins working with newer versions of the application. But again, "plugin/application version conflicts" would be dealt with on an "application logic layer").

Hence I don't need this version numbers, they clutter the application/shared libs directory.

Well, actually I wouldn't mind too much about a version number in the filename, if there was a way to specify my dependencies in a cross-platform way, e.g. like:

VERSION=1.2.3
LIBS += -L/path/to/compiled/libs -lUtils$${VER_MAJ}

(I also tried with $$VER_MAJ, but that variable seems to be emptry)

so qmake would generate the proper link statement, and link against Utils1.dll on Windows and Utils-1.so (or was it Utils1.so, can't remember) on Linux/Mac.

But as I said, VER_MAJ seems to be empty (bug in qmake 4.7.1?).

And this link:
  http://www.qtcentre.org/threads/17984-qmake-how-to-extract-number-from-variable

make me think that other people hit the same problem.

So since I don't really need these VERSION info I wanted to skip this whole think altogether.

> If its a shared library it should have a SOVERSION which means at 
> least 1 number in the whole thing, so that the runtime linking works 
> properly (on Linux that is).

I tried to google SOVERSION (and the first link is another post by you ;) but could not find anything useful which would indicate that it is REALLY required (from a technical point of view, e.g. linker refuses to link or so). It is more a "hint" to indicate on what level the "binary compatibility" might have changed, so if applications would really want to link against libFoo-1.2, they simply would not link of only a libFoo-1.1 was present).

But again, I don't have these requirements! I simply want to

- get rid of these symbolic links and
- have a cross-platform solution for LIBS+= ... -lFoo

And yes, I want to avoid writing LIBS += ...-lFoo1, because that would require me later on to manually edit all my *.pro files when I would go to VERSION=2.0.0 - I am lazy, I don't want that ;) And I want to avoid the "hacky stuff" like parsing VERSION, as suggested in the Qt Centre article.

But maybe I simply don't understand how to properly use VER_MAJ, I would be happy to write e.g.

  LIBS += ... -lFoo$${VER_MAJ}

And I would also actually like to set VERSION in my *.pro files, since it might come handy elsewhere (for Mac application bundles -> Info.plist files, for example - even though currently that only seems to work when building libraries/Frameworks, not applications, see e.g. http://bugreports.qt.nokia.com/browse/QTBUG-7993)


So either I find a way to automagically link against the proper libraries (cross-platform) and using VERSION, or I suppress the VERSION part completely (or "suppress" it with "hacks" like CONFIG+=plugin, which I also don't like - and which does not seem to work anymore on Windows anyway).

Any thoughts? :)

Thanks,
  Oliver
--
Oliver Knoll
Dipl. Informatik-Ing. ETH
COMIT AG - ++41 79 520 95 22