[Plplot-devel] Explanation for need for specific CMAKE_BUILD_TYPE on MinGW

[Alan W. I. <ir...@be...>]

Clint Stimpson was kind enough to explain further on the CMake
developer's list why it is currently necessary to specify
CMAKE_BUILD_TYPE as either Debug or Release with CMake for the
MinGW/Qt4 case. I forward that expanded explanation below.

Richard, I hope when you apply this advice to your PLplot build,
you will find your results are much more reliable.

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
__________________________

---------- Forwarded message ----------
Date: Wed, 22 Jun 2011 22:06:14 -0600
From: Clinton Stimpson <cl...@el...>
To: CMake Developers <cma...@cm...>
Cc: Alan W. Irwin <ir...@be...>
Subject: Re: [cmake-developers] [CMake 0012301]: CMAKE_BUILD_TYPE not set on
     MinGW

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.

Clint