[cmake-developers] [CMake 0012301]: CMAKE_BUILD_TYPE not set on MinGW

[Alan W. Irwin]

On 2011-06-22 22:06-0600 Clinton Stimpson wrote:

> This issue is with how Qt plugins are compiled.  It has come up a couple times in the past, but this might be the first with MinGW.
>
> When Qt is configured, a build key is generated that is configuration specific (see qconfig.h).
> On Windows, the build key for the debug and release libs are different (regardless of the compiler used  -- although they may only need to really do it for MSVC because only it has separate debug and release runtimes).
>
> When a user creates a Qt plugin, that build key gets embedded into the plugin (see build key used in qplugin.h), so it can only be loaded with a compatible Qt build.
> On Windows, the correct debug or release build key needs to be used, and choosing the correct one is dependent on compiling with -DQT_NO_DEBUG or -DQT_DEBUG.  If neither is defined, qglobal.h automatically sets QT_DEBUG, which means it is assuming a debug build, even if one links against the release Qt libs.  I wonder if there is a way to patch Qt to make a better assumption.
>
> So anyway, Stephen was having this issue because the build type was not explicit and Qt assumed debug and CMake assumed Release (by choosing to link with the release Qt libs), and the plugin was compiled with the wrong build key, so it wouldn't load at runtime.  CMake sets a build type by default for MSVC compilers, but not MinGW or MSYS.  The bug report requests that a default build type be specified instead of left empty.
>
Hi Clint:

I looked further at what CMake does currently about this.  Here are
the files in the CMake-2.8.4 source tree that mention QT_NO_DEBUG or
QT_DEBUG

software at raven> find cmake-2.8.4 -type f -print0 |\
xargs -0 egrep -l '(QT_DEBUG|QT_NO_DEBUG)'
cmake-2.8.4/Docs/cmake.html
cmake-2.8.4/Docs/cmake-modules.txt
cmake-2.8.4/Docs/cmake-modules.html
cmake-2.8.4/Docs/cmake.txt
cmake-2.8.4/Docs/cmake-gui.docbook
cmake-2.8.4/Docs/cmake-gui.1
cmake-2.8.4/Docs/cmake.docbook
cmake-2.8.4/Docs/cmake-gui.txt
cmake-2.8.4/Docs/cmakemodules.1
cmake-2.8.4/Docs/cmake.1
cmake-2.8.4/Docs/cmake-gui.html
cmake-2.8.4/ChangeLog.txt
cmake-2.8.4/Modules/UseQt4.cmake
cmake-2.8.4/Modules/FindQt3.cmake
cmake-2.8.4/Modules/FindQt4.cmake

I presume all the Docs ones are generated from FindQt4.cmake and
FindQt3.cmake documentation lines, and we can ignore the
mention in ChangeLog.txt.  That just leaves

cmake-2.8.4/Modules/UseQt4.cmake
cmake-2.8.4/Modules/FindQt3.cmake
cmake-2.8.4/Modules/FindQt4.cmake

I will concentrate on just the Qt4 case.  FindQt4.cmake just documents
QT_NO_DEBUG and QT_DEBUG but takes no action itself.  That just leaves
one file, UseQt4.cmake which has only the following lines concerning those
variables.

SET_PROPERTY(DIRECTORY APPEND PROPERTY COMPILE_DEFINITIONS_DEBUG QT_DEBUG)
SET_PROPERTY(DIRECTORY APPEND PROPERTY COMPILE_DEFINITIONS_RELEASE QT_NO_DEBUG)
SET_PROPERTY(DIRECTORY APPEND PROPERTY COMPILE_DEFINITIONS_RELWITHDEBINFO QT_NO_DEBUG)
SET_PROPERTY(DIRECTORY APPEND PROPERTY COMPILE_DEFINITIONS_MINSIZEREL QT_NO_DEBUG)

Shouldn't the general (Qt4) fix for this bug be to add

SET_PROPERTY(DIRECTORY APPEND PROPERTY COMPILE_DEFINITIONS QT_NO_DEBUG)

to the above lines?  That fix seems simpler and more flexible than
forcing a default CMAKE_BUILD_TYPE for the MinGW case.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state implementation
for stellar interiors (freeeos.sf.net); PLplot scientific plotting software
package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of
Linux Links project (loll.sf.net); and the Linux Brochure Project
(lbproject.sf.net).
__________________________

Linux-powered Science
__________________________