On Wed, Jun 22, 2011 at 9:06 PM, Clinton Stimpson <[email protected]> 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
> [email protected]
> http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
>
_______________________________________________
cmake-developers mailing list
[email protected]
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
