[cmake-developers] Peculiar issue for "NMake Makefiles JOM"

Alan W. Irwin irwin at beluga.phys.uvic.ca
Mon Jun 10 15:43:53 EDT 2013


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
__________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: build_dir.tar.gz
Type: application/octet-stream
Size: 13997 bytes
Desc: compressed build directory generated with --debug-trycompile for the two-line jom/mingw test project
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20130610/029d16d0/attachment-0002.obj>


More information about the cmake-developers mailing list