[CMake] CMake files for static builds of Qt 5

[Stephen Kelly]

Forwarding to the cmake list.

Context: We're discussing the patch at:

https://codereview.qt-project.org/#change,33193

in which a line similar to (eg from QtCore.prl):

QMAKE_PRL_LIBS = -lpthread -lz -licui18n -licuuc -lm -ldl -pthread -
lgthread-2.0 -lrt -lglib-2.0

The line in QtGui.prl looks like:

QMAKE_PRL_LIBS = -L/usr/X11R6/lib64 -ljpeg -L/home/stephen/dev/src/qtbase-
static/lib -lQtCore -lz -licui18n -licuuc -lm -ldl -pthread -lgthread-2.0 -lrt 
-lglib-2.0 -lpthread -lpng -lz -lGL

is parsed out of files with an extension .prl which get shipped alongside the 
Qt libraries (and are created as part of a Qt build). That string is then used 
as the list of dependent libraries for the Qt targets for static builds. 

This is for convenience, so that users of Qt do not have to specify the static 
dependencies themselves, and so that I don't have to maintain the list 
'artificially' in the cmake files in Qt either.

However, there are issues, see below:

On Tuesday, August 21, 2012 16:52:19 Stephen Kelly wrote:
> On Tuesday, August 21, 2012 08:21:01 Clinton Stimpson wrote:
> > On Tuesday, August 21, 2012 01:32:33 PM Stephen Kelly wrote:
> > > This means adding a string of -L and -l entries to the
> > > LINK_INTERFACE_LIBRARIES, which isn't particularly nice, but I don't
> > > think
> > > it has a downside, unless you see one?
> > 
> > Doesn't that add -L and -l entries for the Qt libraries themselves as
> > well?
> 
> Yes, it does.
> 
> > For example, QtGui depends on QtCore, and is there a -lQtCore in QtGui's
> > prl file.
> 
> Yes. I'm not really aware of what kinds of problems that causes though.
> 
> > This kind of thing prevents being able to create cmake export files and
> > have them work on other Linux machines which may have a different
> > location these system libraries.
> 
> Yes, I suppose this set-up assumes that the static Qt and the user of it are
> built with the same environment.
> 
> > Maybe we already had that problem, but with the old way,
> > we could fix the Find* files in CMake.  With this way, we can't fix the
> > prl
> > files.
> 
> Yes, although prl files are also just text files. Arguably if someone is
> moving a Qt installation to another machine or environment (I'm not sure
> that's supposed to work anyway) maybe they should change those prl files
> too.
> 
> Moving to a different machine/environment means that those libraries could
> have been built with different flags/be different versions etc. Building
> third party software against this 'moved' Qt might then be using a
> different static library than the Qt itself. Would you really expect that
> to work all the time? It sounds hacky to even attempt.
> 
> > It feels like going against the grain of CMake's way of handling
> > libraries.
> 
> Yes, but it is the maintainable solution unfortunately.

So, for the cmake list - Is moving a static library (Qt in this case) to an 
evironment different from the build environment expected to work? 

If QtCore is built statically against icuuc version 46 and then moved to an 
environment where icu version 48 is available, but not 46, and you build your 
software linked with the static Qt and the other version of icu, do you expect 
it to work? Consdier the query repeated with any library dependency you like.

Thanks,

-- 
Stephen Kelly <stephen.kelly at kdab.com> | Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090
KDAB - Qt Experts - Platform-Independent Software Solutions
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://www.cmake.org/pipermail/cmake/attachments/20120822/351087cd/attachment.pgp>