I have been testing the OPTIONAL signature for enable_language using the
following simple CMakeLists.txt file:
*******
cmake_minimum_required(VERSION 2.6.4)
project(test NONE)
enable_language(C OPTIONAL)
message(STATUS "CMAKE_C_COMPILER_WORKS = ${CMAKE_C_COMPILER_WORKS}")
*******
According to the documentation the OPTIONAL signature is to help CMake-based
build systems deal smoothly with bad/broken compilers by allowing them to
take their own actions to deal with the compiler issue based on the value of
CMAKE_<languageName>_COMPILER_WORKS. However, the OPTIONAL signature does
not work and bad/broken compilers error out before the above message command
can be reached. The same issue also occurs for C++ and Fortran.
To illustrate the issue as simply as possible, I emulate a missing/broken
compiler as follows:
softw...@raven> CC='gcc whatever' cmake ..
-- The C compiler identification is unknown
-- Check for working C compiler: /usr/bin/gcc
-- Check for working C compiler: /usr/bin/gcc -- broken
CMake Error at
/home/software/cmake/install-2.6.4/share/cmake-2.6/Modules/CMakeTestCCompiler.cmake:32
(MESSAGE):
The C compiler "/usr/bin/gcc" is not able to compile a simple test program.
It fails with the following output:
Change Dir: /tmp/build_dir/CMakeFiles/CMakeTmp
Run Build Command:/usr/bin/make "cmTryCompileExec/fast"
/usr/bin/make -f CMakeFiles/cmTryCompileExec.dir/build.make
CMakeFiles/cmTryCompileExec.dir/build
make[1]: Entering directory `/tmp/build_dir/CMakeFiles/CMakeTmp'
/home/software/cmake/install-2.6.4/bin/cmake -E cmake_progress_report
/tmp/build_dir/CMakeFiles/CMakeTmp/CMakeFiles 1
Building C object CMakeFiles/cmTryCompileExec.dir/testCCompiler.c.o
/usr/bin/gcc whatever -o CMakeFiles/cmTryCompileExec.dir/testCCompiler.c.o
-c /tmp/build_dir/CMakeFiles/CMakeTmp/testCCompiler.c
gcc: whatever: No such file or directory
make[1]: Leaving directory `/tmp/build_dir/CMakeFiles/CMakeTmp'
make[1]: *** [CMakeFiles/cmTryCompileExec.dir/testCCompiler.c.o] Error 1
make: *** [cmTryCompileExec/fast] Error 2
CMake will not be able to correctly generate this project.
Call Stack (most recent call first):
CMakeLists.txt:3 (enable_language)
-- Configuring incomplete, errors occurred!
The "whatever" inserts an extra unknown file into the compilation process
which makes try_compile not work, and which therefore tests the OPTIONAL
signature. However, instead of returning properly to the original
CMakeLists.txt file to allow the build system to do something about
CMAKE_C_COMPILER_WORKS being false it errors out as above.
The source of the issue is line 32 of CMakeTestCCompiler.cmake which
uses message(FATAL_ERROR ...)
If you change that to message(STATUS ...) , then that solves the issue and
control is returned back to the originating CMakeLists.txt file with this
(correct) result
[...]
CMake will not be able to correctly generate this project.
-- CMAKE_C_COMPILER_WORKS = FALSE
-- Configuring done
-- Generating done
-- Build files have been written to: /tmp/build_dir
However, that is not a good general solution because the same fix means that
if you drop OPTIONAL, i.e., use "enable_language(C)" control is incorrectly
returned to the original CMakeLists.txt and the project is incorrectly
configured and generated without a CMake error.
I had a look at cmEnableLanguageCommand.cxx to see what it did with
OPTIONAL. It appears that it simply lets the Generator know that the
language is optional. I suggest it should also set a CMake variable that
CMakeTestCCompiler.cmake (and also CMakeTestCXXCompiler.cmake and
CMakeTestFortranCompiler.cmake) could use to send STATUS or FATAL_ERROR
messages as appropriate.
The reason I am bringing up these OPTIONAL C, C++, and Fortran language
support issues now is I am beginning to encounter reports from PLplot users
with broken compilers, and I would prefer to give them a much smoother
landing (disable that part of PLplot that depends on the compiler in
question with a warning message and keep going) than is possible now. Once
the OPTIONAL signature to enable_language actually works, I presume a
substantial number of other multi-language projects would find it useful as
well.
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); PLplot scientific plotting software
package (plplot.org); 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
__________________________
_______________________________________________
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
