Re: [Mingw-cross-env-list] Qt with Cmake

[Mark Brand]

> > Anyway, it's not clear to me why cmake would need to be told that the Qt
> > libraries are static. It just needs to know the dependencies of the
> > libraries used, and these should be in the .prl files. Obviously the .prl
> > files will differ depending whether the libraries they describe are static
> > or shared.
> >
> > Mark
> Sounds logical. I did some more testing just to closely see what was
> getting linked and what was not and whether it was trying static or
> dynamic linking. And it all looked correct. So I went back to setting
> and unsetting -DQT_DLL making sure that QT_LIBRARIES was the same in
> both situations. Without, it compiles fine, with it, it dies with
> undefined references. The FindQt4.cmake files set this on by default
> unless there's something in that global qconfig.pri file.

I'm not sure if this is part of the issue, but don't forget that the Qt 
libraries have different names in Windows depending on whether they are 
static or shared.

> So, it looks like windows does absolutely need to be told via QT_DLL
> macro if qt was statically built or dynamically built - this affects
> how the applications cpp files (aka my main.cpp) are built.
>
> 1) Should QT_DLL be set/not set using a decision better than looking
> up qconfig.pri for 'static'? Can it be automatic?

I think qmake must do that by considering the mkspec. It looks like 
mkspecs/features/qt.prf is responsible for QT_DLL.

> 2) Parsing the prl's, if available, guarantee that you don't miss any
> dependencies when statically compiling. Is it useful when dynamically
> linking?

Don't forget that static and shared linking can be used together. For 
example, if you build shared Qt on mingw-cross-env where everything else 
is static, the shared Qt libs will have static dependencies that will 
have to be explicitly linked to your application. The .prl files can 
help with that.

Mark