On 2013-06-10 10:58-0400 Bill Hoffman wrote:
The CMakeError.log you requested was not too informative: bash.exe-3.1$ cat CMakeFiles/CMakeError.log Determining if the C compiler works failed with the following output:Next step is to try it by hand. Start with a clean build tree and your simple project. Then run cmake with --debug-trycompile option.This will leave all the temp files in CMakeFiles. You can then run it by hand and see what the error is. There should be a makefile in CMakeTmp, that you can run jom or nmake in and see what the error actually is.
I have packed up the whole build directory from
/z/home/wine/newstart/test_jom (see attached) for you to look at since
that tarball is quite small for that two-line CMakeLists.txt test case
run with --debug-trycompile and starting from an empty build tree as
you suggested. Here are a few of the details from the
CMakeFiles/CMakeTmp part of that.
The created project is
cmake_minimum_required(VERSION 2.8.10.2)
PROJECT(CMAKE_TRY_COMPILE C)
SET(CMAKE_VERBOSE_MAKEFILE 1)
SET(CMAKE_C_FLAGS " ${COMPILE_DEFINITIONS}")
INCLUDE_DIRECTORIES(${INCLUDE_DIRECTORIES})
SET(CMAKE_SUPPRESS_REGENERATION 1)
LINK_DIRECTORIES(${LINK_DIRECTORIES})
SET(CMAKE_RUNTIME_OUTPUT_DIRECTORY
"Z:/home/wine/newstart/test_jom/build_dir/CMakeFiles/CMakeTmp")
ADD_EXECUTABLE(cmTryCompileExec2507081881
"Z:/home/wine/newstart/test_jom/build_dir/CMakeFiles/CMakeTmp/testCCompiler.c")
TARGET_LINK_LIBRARIES(cmTryCompileExec2507081881 ${LINK_LIBRARIES})
I obviously cannot run that here because I would just run into the
same error from the attempt to enable C. However, I did try
gcc testCCompiler.c
by hand, and that compiled with no warning or error messages of any
kind and with a return code of 0. So I don't know what could be wrong,
but hopefully you can figure it out from the attached results.
I just checked download statistics from the mingw SourceForge site for the gcc-4.7.2 core package alone (not the sum of all gcc-4.7.2-related packages which, of course, has much larger download statistics) and it has averaged 20000 downloads (!) a month for the 7 months since its release. That's a lot of developers and potential users of CMake on Windows. Therefore, it would likely be a good idea to make most Windows-based generators (such as "NMake Makefiles" and "NMake Makefiles JOM") work correctly with the MinGW suite of compilers. I am assuming here this would be a fairly trivial task for a developer who was familiar with the CMake language-support infrastructure.This type of stuff does no good in figuring out what is wrong. I really don't care how popular it is. However, now that you bring it up... It also comes with its own make program which for the most part is far superior to nmake or jom. gmake is able to do parallel builds much better, and they finally added the jobserver stuff to the mingw gmake, so I would say that is the build tool to use for that environment. ninja might be more interesting to look at as it is better than gmake in many ways. However, I am thinking not many of those 20000 downloads would be interested in nmake or jom.
My point here was simply the downloads for the MinGW core package (actually 140000 for the 7 months since release and still going strong at the rate of 20000 per month) indicate the enormous popularity of this compiler suite which is one factor to consider. I do acknowledge your point that _if_ mingw32-make (available with MinGW) and make (available with MSYS) prove to be substantially more efficient than jom, there may be no point in supporting the MinGW suite of compilers for "NMake Makefiles JOM". But I don't think we can just assume jom inefficiency for this case so facts about that efficiency (and ninja's when I get to it) versus the MinGW and MSYS make build tools are something I would like to be in position to discover. So I hope whatever is wrong in the attached results will be easy to figure out. 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 __________________________
build_dir.tar.gz
Description: compressed build directory generated with --debug-trycompile for the two-line jom/mingw test project
-- 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
