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

Reply via email to