Hi Hazen: This is mostly addressed to you, but there is a question at the end for all our developers.
On 2009-07-23 12:23-0400 Hazen Babcock wrote: > [...]I think I managed to figure out a > few things. Maybe the problem is with the cmake command that is used to test > the c++ compiler (the one that is run by language_support.cmake)? If I run > the same command by hand: > > xx\plplot_build\language_tests\CXX>"c:\Program Files\CMake 2.6\bin\cmake.exe" > . > > I get: > > CMake Error: CMake was unable to find a build program corresponding to > "Visual Studio 6". CMAKE_MAKE_PROGRAM is not set. You probably need to select > a different build tool. > > Anyway, if I simply comment out the workaround_9220 section in c++.cmake then > I can build PLplot with the Qt drivers and (untested) PyQt4 support so it all > looks very promising. Thanks for that information which I think contains a strong clue about what is happening. workaround_9220 does a small test run of the cmake command to check the language support. But when executing that test run, it just invoked cmake with no generator specified. That default won't work if an overall generator is specified (which I assume it true in your case). To fix this I propagated the overall generator to the test run (revision 10176). Please give that a try. Note, there are quite a few ways within CMake to choose a compiler such as specifying CMAKE_<lang>_COMPILER or CMAKE_<lang>_COMPILER_INIT. There are also a large plethora of ways to specify options for any given compiler. workaround_9220 ignores all of that because I think it is too complicated to propagate all the possibilities while still insuring a reliable result. workaround_9220 should work fine if you use the default compiler for your generator or if you have specified the compiler (and flags) with the appropriate environment variable, e.g., export CXX="g++ -g -fvisibility=hidden" since the environment variable should just propagate to the test cmake run. I am inclined to simply say in the release notes that until CMake bug 9220 is fixed, we do not support any methods of specifying the compiler for the soft landing logic other than using the appropriate environment variable. I could also implement a WORKAROUND_9220 option which defaults to ON, but which in an emergency the user can set to OFF if he wants the most comprehensive compiler detection but is willing to accept hard landings. To all developers here, please let me know whether you think a WORKAROUND_9220 option is overkill or not (i.e., do you think the vast majority of our users use the environment variable approach for specifying the compiler and compiler options). 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 __________________________ ------------------------------------------------------------------------------ _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
