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. 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 __________________________ _______________________________________________ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers