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

[Clinton Stimpson]

On Thursday, June 23, 2011 10:45:25 am Alan W. Irwin wrote:
> 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.
> 

Yeah, I came to the same conclusion and committed a fix.
http://cmake.org/gitweb?p=cmake.git;a=commit;h=5a2b20
I also made note of that on the thread in the cmake list and in the bug 
report.

I wonder if this will make it into 2.8.5?

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