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

[J Decker]

On Wed, Jun 22, 2011 at 9:06 PM, Clinton Stimpson <clinton at elemtech.com> wrote:
>
> On Jun 22, 2011, at 9:11 PM, Alan W. Irwin wrote:
>
>> On 2011-06-22 17:36-0400 Mantis Bug Tracker wrote:
>>
>>>
>>> The following issue has been SUBMITTED.
>>> ======================================================================
>>> http://public.kitware.com/Bug/view.php?id=12301
>>> ======================================================================
>>> Reported By:                Stephen Kelly
>>> Assigned To:
>>> ======================================================================
>>> Project:                    CMake
>>> Issue ID:                   12301
>>> Category:                   CMake
>>> Reproducibility:            always
>>> Severity:                   minor
>>> Priority:                   normal
>>> Status:                     new
>>> ======================================================================
>>> Date Submitted:             2011-06-22 17:36 EDT
>>> Last Modified:              2011-06-22 17:36 EDT
>>> ======================================================================
>>> Summary:                    CMAKE_BUILD_TYPE not set on MinGW
>>> Description:
>>>
>>> CMAKE_BUILD_TYPE is not set when using MinGW, which causes problems with loading
>>> Qt plugins unless the user manually sets the CMAKE_BUILD_TYPE.
>>>
>>> CMAKE_BUILD_TYPE should be preset to debug or release, as it is on most other
>>> platforms.
>>>
>>> Context here:
>>>
>>> http://thread.gmane.org/gmane.comp.programming.tools.cmake.user/36994/focus=37032
>>
>> I have an interest is this bug report and the above thread because of
>> my MinGW/wine tests and experiments with the Qt4 components of PLplot.
>> Also, we currently have a user who is having a devil of a time getting
>> the Qt4 components of PLplot to work reliably on Windows.
>>
>> I have read that thread, but would some MinGW/Windows expert here
>> (such as, ahem, Clint) explain what the real issue is?
>>
>> On Linux, CMAKE_BUILD_TYPE is also not set, but the Qt4 aspects of our
>> PLplot build work fine there.  In other words, the "Unix Makefiles"
>> generator and associated CMake Linux gcc compiler support know exactly
>> what to do if the CMAKE_BUILD_TYPE is not set.  (I assume from the
>> documentation that means that the release version of Qt4 is chosen
>> rather than the debug version, but I haven't verified that.) So is the
>> issue really that either/both of "MinGW Makefiles" or "MSYS Makefiles"
>> combined with the CMake Windows MinGW compiler support don't know how
>> to correctly handle the case where CMAKE_BUILD_TYPE is not set?
>>
>> Currently, I must say I have sometimes had success with the Qt4
>> components of PLplot on wine and sometimes not, and I haven't yet
>> pinned down the reason.  And we have a PLplot user with very similar
>> Qt4/PLplot reliability issues using MinGW on the Microsoft version of
>> Windows.  Because of the information in the above bug report I will
>> try manually setting CMAKE_BUILD_TYPE (I haven't done that before) the
>> next time I build and test PLplot on wine, and I have suggested our
>> user do the same on Microsoft Windows, in the hope it will make the
>> Qt4 components of PLplot more reliable on those platforms.
>>
>> Clint, I had planned to restart MinGW/MSYS/Wine and MinGW/Wine testing
>> of PLplot builds in the next several weeks, but I could start those
>> tests earlier if it would clarify some of the issues you discovered for the
>> case when CMAKE_BUILD_TYPE was not set manually.
>
> 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.
>

Think some cmake script should be modified to specify the default
build types as a drop list for the gui with a default of what cmake
would be (I guess release); there's probably a core module that's
loaded always?

set(CMAKE_BUILD_TYPE "Debug" CACHE STRING "Set build type")
set_property(CACHE CMAKE_BUILD_TYPE PROPERTY STRINGS
${CMAKE_CONFIGURATION_TYPES} Debug Release RelWithDebInfo MinSizeRel )

but if a specific project uses a different variable instead of the
standard one; it's of no help... might help encourage migration to
standard though...

> Clint
>
> _______________________________________________
> cmake-developers mailing list
> cmake-developers at cmake.org
> http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
>