On 2014-03-06 05:38-0800 phil rosenberg wrote: > Hi Alan
> Unfortunately (or fortunately, depending upon your viewpoint) a simple test case that I ran for Brad showed that CMake was reporting the 64 bit compiler correctly, so indicates something deeper in the Plplot build system is happening. Unfortunately it is beyond my skills with CMake to find it, although I have looked. It almost seems like sometime before the findwxWidgets module is called the variables relating to the compiler all get changed or reset somehow. Hi Phil: Although you have a workaround, I hope you are still game to continue (with some additional help from me, see below) since ideally we want our FindwxWidgets.cmake in cmake/modules to match the latest official version without any workarounds necessary. (Such matching would allow us to delete our version in the future once the latest official CMake version had been released, and once our CMake minimum version had been set in such a way as to force all our users to use that released version of CMake rather than some prior version). So here is the present status of the changes you have made relative to the latest official (but unreleased) version that I obtained from http://cmake.org/gitweb?p=cmake.git;a=blob_plain;f=Modules/FindwxWidgets.cmake;h=3c664e7f32c8cf764e6da99f9146d8754d8db508;hb=2cd55978 --- FindwxWidgets.cmake_latest 2014-03-06 09:39:21.544166057 -0800 +++ FindwxWidgets.cmake 2014-03-06 09:56:26.550372591 -0800 @@ -503,15 +503,36 @@ set(wxWidgets_LIB_DIR "wxWidgets_LIB_DIR-NOTFOUND" CACHE PATH "Cleared." FORCE) endif() - + #include(CMakeDetermineCCompiler) + #message(STATUS "CMAKE_CROSSCOMPILING = ${CMAKE_CROSSCOMPILING}") + #message(STATUS "CMAKE_C_COMPILER = ${CMAKE_C_COMPILER}") + #message(STATUS "MSVC_C_ARCHITECTURE_ID = ${MSVC_C_ARCHITECTURE_ID}") + #message(STATUS "MSVC_CXX_ARCHITECTURE_ID = ${MSVC_CXX_ARCHITECTURE_ID}") + #message(STATUS "CMAKE_CL_64 = ${CMAKE_CL_64}") + #message(STATUS "LIB = $ENV{LIB}") + #message(STATUS "GENERATOR = ${CMAKE_GENERATOR}") if(WX_ROOT_DIR) # Select one default tree inside the already determined wx tree. # Prefer static/shared order usually consistent with build # settings. if(MINGW) set(WX_LIB_DIR_PREFIX gcc) + #The following should check for compiling 64 bit with nmake or VS + #Check for use of 64 bit NMake Makefile generator or a Visual Studio XX Win64 generator elseif(CMAKE_CL_64) set(WX_LIB_DIR_PREFIX vc_x64) + #unfortunately the above doesn't work on my system - can't find why, but workaround below + #Check for vs64 bit + elseif(${CMAKE_GENERATOR} MATCHES "Win64$") + set(WX_LIB_DIR_PREFIX vc_x64) + #Check for nmake 64 bit + elseif(${CMAKE_GENERATOR} STREQUAL "NMake Makefiles") + set(WX_LIB_DIR_PREFIX vc) + foreach(ENVLIBDIR $ENV{LIB}) + if( ENVLIBDIR MATCHES "amd64$") + set(WX_LIB_DIR_PREFIX vc_x64) + endif() + endforeach() else() set(WX_LIB_DIR_PREFIX vc) endif() @@ -865,7 +886,7 @@ #===================================================================== #===================================================================== -include(${CMAKE_CURRENT_LIST_DIR}/FindPackageHandleStandardArgs.cmake) +include(FindPackageHandleStandardArgs) FIND_PACKAGE_HANDLE_STANDARD_ARGS(wxWidgets DEFAULT_MSG wxWidgets_FOUND) # Maintain consistency with all other variables. set(wxWidgets_FOUND ${WXWIDGETS_FOUND}) Comments: (1) You should not be too concerned about your CMake debugging skill since you are obviously picking that up in a hurry; you have already demonstrated one fundamental debugging skill above which is to insert lots of message statements, and you are also well on your way to the other required skill which is to make simple examples of PLplot build-system issues you discover. (2) To obtain the above patch without any interference from line endings I had run the following svn command (and committed that result as of revision 13046). svn propset svn:eol-style native FindwxWidgets.cmake FindFreetype.cmake Setting this svn property is always necessary for new _text_ files (such as these) that you commit. The "native" value of this property simply means a checkout will convert from the internal repository line endings to the appropriate line endings for the platform. We obviously want that to happen for all text files, but not for binary files since the binary files would be screwed up by such a change. Note it is likely you won't have to worry about this ever again since the next time you add a text file we will likely be using a git repository where by default (according to my reading about git repositories) all text files have the desired "native" property without the committer having to do anything special as in the svn case to set that property. (3) I am concerned about the (commented out) include(CMakeDetermineCCompiler) command you obviously used in your debugging. First of all, C is the wrong language, and it should be C++ (i.e., CMakeDetermineCXXCompiler) instead. Second CMakeDetermineCXXCompiler.cmake should be automatically invoked at the right time for the specified generator when you enable C++. So to invoke the logic in CMakeDetermineCXXCompiler.cmake or CMakeDetermineCCompiler.cmake again (as in the above commented out statement) may lead to problems or inconsistencies. So when I obtain your simple test case (see request below) the first thing I will do with it is to remove all statements like the above, and instead enable the C++ language similarly to how it is done for PLplot, e.g., cmake_minimum_required(VERSION 2.8.12.2 FATAL_ERROR) # Only enable the C language to start to follow what is done for # PLplot. project(test_CMAKE_CL_64 C) # Don't bother with PLplot workaround to provide a soft # landing when a compiler does not work, but # otherwise enable C++ like PLplot enable_language(CXX OPTIONAL) (4) All but two of the official CMake find modules in my present system use the include(${CMAKE_CURRENT_LIST_DIR}/FindPackageHandleStandardArgs.cmake) form rather than the include(FindPackageHandleStandardArgs) form. Therefore, the last change you made above (which may have slipped in by accident) is probably not a good idea, and although it obviously works for both of us, I suggest you commit the include(${CMAKE_CURRENT_LIST_DIR}/FindPackageHandleStandardArgs.cmake) form (which should also work for both of us since that form is ubiquitous in most find modules) just to minimize differences with the official find module. (5) It appears from the above that your use of workarounds for both the ${CMAKE_GENERATOR} MATCHES "Win64$" and ${CMAKE_GENERATOR} STREQUAL "NMake Makefiles" cases is simply because CMAKE_CL_64 is not defined for those two generators for the PLplot build system. Assuming the lack of CMAKE_CL_64 for those two generators is the fundamental PLplot build-system issue which you could not replicate with a simple example, then please send that simple example to me so I can compare what that simple example does with what the PLplot build system does. >From such a comparison I may be able to figure out a small change to the simple example (e.g., to enable the C++ language in an identical way to the PLplot case as suggested above) that will trigger the issue. Note that CMake supports three ways to enable languages (one in the project statement and two with the enable_language statement with or without the OPTIONAL keyword). In the past some of those ways have been problematic compared to others. So you may simply have found generator bugs for the particular way that PLplot enables C++ (see above) and as soon as you change to that PLplot method for enabling languages, the simple example may demonstrate the same bug that you found for the full PLplot build system. 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
