On 2014-03-07 03:28-0800 phil rosenberg wrote: > The (very)simple example is attached - it can be run simply with cmake > "dir/of/example" -G "Visual Studio 11 Win64"
> You might well be able to run this on Wine or something as I'm told visual studio generators do not actually need access to the compiler like the nmake generator does. Hi Phil: I tried that but that generator does not work for my Wine platform. The error message was CMake Error: CMake was unable to find a build program corresponding to "Visual Studio 11 Win64". CMAKE_MAKE_PROGRAM is not set. You probab ly need to select a different build tool. i.e., that generator is checking that I have the appropriate version of Visual Studio installed (which I do not) on my Wine platform. Also, to keep my Wine installation as simple as possible I have only installed 32-bit Wine and not the 64-bit version so it would not be a good test case that was comparable to your 64-bit platform. I assume from your remarks that when you run this simple test case on your platform the expected values of CMAKE_CL_64 and CMAKE_C_COMPILER are printed, but you get a different result for the PLplot build system. What happens if you follow my suggestion to mimic more closely the PLplot build system, by inserting the command enable_language(CXX OPTIONAL) (see cmake/modules/c++.cmake) just after the "project(Issue14693 C)) statement in your simple example? Do you continue to get the expected results for CMAKE_CL_64 and CMAKE_C_COMPILER or does that change those results to the bad results you get for the case of the PLplot build system? If that changes generates bad results, then you have a simple test case to take to Brad King. On the other hand, if that slightly modified version of the simple test case continues to give expected results for those variables, then the next thing to try is to simplify the PLplot build system as much as possible (on the assumption some component that build system is interfering with the expected value of those variables). To do that use the cmake options -DDEFAULT_NO_DEVICES=ON (which shuts down all devices except those you mention explicitly) and -DDEFAULT_NO_BINDINGS=ON (which shuts down all bindings except those you mention explicitly). If you don't specify any devices or bindings, that should end up building nothing but our core C library and its internal dependencies. If for that case CMAKE_CL_64 and CMAKE_C_COMPILER are fine, then you can gradually add back components, (e.g., use -DDEFAULT_NO_DEVICES=ON -DPLD_wxwidgets -DDEFAULT_NO_BINDINGS=ON -DENABLE_CXX=ON to add back just C++ and our wxwidgets device driver) to find the critical component of our build system that is interfering with CMAKE_CL_64 and CMAKE_C_COMPILER on your platform. I also suggest for the PLplot build system that you use message to print out those variables just after the project command, the above enable_language(CXX ...) command and right at the end of the cmake/modules/wxwidgets.cmake code to see if there are any changes to the results for those variables in those various critical locations. (In fact, that first location could give identical results to your current [without C++ enabled] simple example since essentially the identical commands are being used in the two cases.) Good luck with this bug hunt, and let me know how it goes since I am quite interested in helping as much as I can with your efforts to solve this issue. 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); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); 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 __________________________ ------------------------------------------------------------------------------ Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce. With Perforce, you get hassle-free workflows. Merge that actually works. Faster operations. Version large binaries. Built-in WAN optimization and the freedom to use Git, Perforce or both. Make the move to Perforce. http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk _______________________________________________ Plplot-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/plplot-devel
