Thanks Bill and Bill for looking into this!
I don't know if this was clear in my original post, but is seems that
most of my troubles with CMake on my system stem from the fact that I
have nearly half-a-dozen MinGW/MSYS installs on my system; each exists
for a specific purpose, and each has it's own version of make:
c:\MinGW-32\bin\make.exe
c:\MinGW-64\bin\make.exe
c:\OSGeo4W\apps\msys\bin\make.exe
c:\Program Files (x86)\pythonxy\mingw\bin\make.exe
c:\RTools\bin\make.exe
None of these fits the patterns given in Modules/CMakeMinGWFindMake.cmake!
I thought that I had expunged all references to MinGW in my system PATH
variable, but it seems that one snuck in anyway. Somehow CMake was
identifying 64-bit libraries in spite of the definitions (i.e.
CMAKE_C_COMPILER, CMAKE_FORTRAN_COMPILER, etc.) all pointing to the
32-bit version of MinGW.
I am now able to get Cmake to work by doing the following:
1) sanitize PATH variable of any MinGW references
2) create custom instance of cmd.exe in which LIB, INCLUDE, and
CMAKE_MAKE_PROGRAM are defined
3) start CMake-gui from the command-line within the above environment
CMake still claims CMAKE_MAKE_PROGRAM is undefined (why??), but after
defining this within the GUI, I now get a working build.
It would still be nice to have an easy way to override all the Windows
registry and environment variables to ensure that CMake is targeting the
appropriate toolchain. For whatever reason, I've never been able to get
CMake to find make, ar, sh etc. on my system via the CMake find_program
commands.
Thanks! - Steve
_______________________________________________
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
