[CMake] CMake files for static builds of Qt 5

[Clinton Stimpson]

On Wednesday, August 22, 2012 05:03:47 PM Stephen Kelly wrote:
> 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,

To clarify, I wasn't talking about moving Qt.  I was talking about a pre-
compiled libraries that depend on Qt being put on another machine, along with 
their cmake export files.

The QMAKE_PRL_LIBS has paths
-L/usr/X11R6/lib64
-L/home/stephen/dev/src/qtbase-static/lib

And I'm concerned those paths would show up in the export file.


Also, I dislike adding "-L/home/stephen/dev/src/qtbase-static/lib -lQtCore" 
when we already have /home/stephen/dev/src/qtbase-static/lib/libQtCore.so when 
using QtGui.

-- 
Clinton Stimpson
Elemental Technologies, Inc
Computational Simulation Software, LLC
www.csimsoft.com