View Issue Details [ Jump to Notes ] [ Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0009220CMakeCMakepublic2009-06-29 18:332016-06-10 14:30
ReporterAlan W. Irwin 
Assigned ToKitware Robot 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionmoved 
PlatformOSOS Version
Product VersionCMake-2-6 
Target VersionFixed in Version 
Summary0009220: enable_language(.... OPTIONAL) signature does not work correctly
DescriptionI 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:

software@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.
TagsNo tags attached.
Attached Files? file icon language_support.cmake [^] (1,285 bytes) 2009-07-16 19:45
? file icon language_support_v2.cmake [^] (2,248 bytes) 2009-08-22 22:23

 Relationships
related to 0008345closed enable_language(fortran optional) fails if no fortran compiler is installed 
related to 0010227closed OPTIONAL option for enable_language(FORTRAN) 

  Notes
(0016780)
Alan W. Irwin (reporter)
2009-06-29 19:45

 Also CMakeDetermineCCompiler.cmake, CMakeDetermineCXXCompiler.cmake, CMakeDetermineFortranCompiler.cmake, and CMakeDetermineRCCompiler.cmake need to be dealt with as well since they generate FATAL_ERROR messages if the CC, etc., environment variables point to a non-existing compiler.
(0016887)
Alan W. Irwin (reporter)
2009-07-16 19:52

 The attached file, language_support.cmake contains a useful function called workaround_9220 which implements David Cole's idea of invoking a cmake session from within your principal cmake session to independently test language support for needed languages before optionally trying enable_language "for real". But the better solution, of course, is simply to fix this bug.
(0017180)
Greg Sharp (reporter)
2009-08-22 22:22
edited on: 2009-08-22 23:10

 Nice workaround airwin. Just what I needed. I have modified your workaround to address 0008345 as well (language_support_v2.cmake above).

On debian testing (cmake 2.6.2), I get return code zero when calling cmake the first time, but cmake crashes when running a second time as follows:

  -- The Fortran compiler identification is unknown
  CMake Error at /usr/share/cmake-2.6/Modules/CMakeFortranInformation.cmake:7 (GET_FILENAME_COMPONENT):
    get_filename_component called with incorrect number of arguments
  Call Stack (most recent call first):
    CMakeLists.txt:3 (enable_language)

My workaround is to invoke cmake twice. If both return codes are zero, then it is safe to invoke ENABLE_LANGUAGE(Fortran OPTIONAL)
(0018597)
Marcel Loose (developer)
2009-11-25 18:13

 With respect to the "ENABLE_LANGUAGE(Fortran OPTIONAL)" and the "get_filename_component called with incorrect number of arguments" issue:
this happens because ${CMAKE_Fortran_COMPILER} is empty. I could resolve that by simply putting quotes around the argument ${CMAKE_Fortran_COMPILER} in the call to GET_FILENAME_COMPONENT() in CMakeFortranInformation.cmake. But I don't know if I'm overlooking all kinds of side effects.
(0018600)
Marcel Loose (developer)
2009-11-27 04:00

 Here's a little work-around that I use to circumvent the error in GET_FILENAME_COMPONENT in CMakeFortranInformation.cmake. It seems to work fine.

# Work-around for CMake issue 0009220
if(DEFINED CMAKE_Fortran_COMPILER AND CMAKE_Fortran_COMPILER MATCHES "^$")
  set(CMAKE_Fortran_COMPILER CMAKE_Fortran_COMPILER-NOTFOUND)
endif(DEFINED CMAKE_Fortran_COMPILER AND CMAKE_Fortran_COMPILER MATCHES "^$")
(0026593)
David Cole (manager)
2011-05-25 16:59

 Not for 2.8.5 - postponing until a future release
(0027476)
David Cole (manager)
2011-09-22 16:56

 Not enough time left to address this issue before the 2.8.6 release. Deferred until a future release.
(0029507)
sleske (reporter)
2012-05-18 10:12

 Update: This bug still exists in CMake version 2.8.8.

Also, it not only manifests if the variable CC is set incorrectly, but also if the installed compiler really does not work.

For example, it is also reproducible (on Linux) by replacing /usr/bin/gcc with /bin/false. So the bug is not only triggered by an incorrect environment setting.
(0029510)
sleske (reporter)
2012-05-18 10:39

 Also, a note about the workaround by Marce Loose (comment 0018600):

This workaround allows the build to run, however it has a side effect.

When using the Makefile generator, the CMake configuration phase will be re-run on every invokation of "make". Usually invoking "make" should only run the actual build (unless CMakeLists.txt was modified).

This does not break the build, but for projects with complex CMake configuration, it significantly slows down the build, especially if only few files need to be rebuilt.
(0029517)
Marcel Loose (developer)
2012-05-21 08:20

 If my solution (c18600) causes a rerun of CMake, then maybe CMAKE_Fortran_COMPILER should be set to CMAKE_Fortran_COMPILER-NOTFOUND in the cache. I've never experienced any problems, though.
(0029533)
sleske (reporter)
2012-05-21 15:06
edited on: 2014-09-10 16:36

 @Marcel Loose:

The problem is easy to reproduce.

CMakeLists.txt:

************
cmake_minimum_required(VERSION 2.6.4)
project(test NONE)
if(DEFINED CMAKE_Fortran_COMPILER AND CMAKE_Fortran_COMPILER MATCHES "^$")
    set(CMAKE_Fortran_COMPILER CMAKE_Fortran_COMPILER-NOTFOUND)
endif(DEFINED CMAKE_Fortran_COMPILER AND CMAKE_Fortran_COMPILER MATCHES "^$")
enable_language(Fortran OPTIONAL)
message(STATUS "CMAKE_Fortran_COMPILER_WORKS = ${CMAKE_Fortran_COMPILER_WORKS}")
************

If no Fortran compiler is installed:

$ cmake .
-- The Fortran compiler identification is unknown
-- CMAKE_C_COMPILER_WORKS =
-- Configuring done
-- Generating done
-- Build files have been written to: test-cmake
$ make
-- The Fortran compiler identification is unknown
-- CMAKE_Fortran_COMPILER_WORKS =
[... etc...]

Normally, invoking "make" should not rerun the CMake configuration phase.

Note: If the compiler is found, "make" does not rerun CMake, as expected.

*Update (2014-09-10):* I can reproduce this with CMake 2.6.4, but not with 2.8.12.2. Looks like it has been fixed :-).
(0031650)
David Cole (manager)
2012-11-21 14:57

 Un-assigning bugs that are not on the active roadmap, which no developers are actively working on for the CMake 2.8.11 release.

If one gets put back on the roadmap, re-assign it appropriately at that time.
(0031671)
David Cole (manager)
2012-11-21 15:11

 Re-setting status back to "new" for bugs that are "assigned" but not assigned to a specific developer. When/if these bugs go back on the roadmap for a specific version, assignment to an appropriate developer should take place then...
(0037940)
Brad King (manager)
2015-02-06 14:15

 For reference, as of CMake 3.1 the enable_language documentation:

 http://www.cmake.org/cmake/help/v3.1/command/enable_language.html [^]

states that OPTIONAL is a placeholder that does not work. AFAICT it never worked, was only ever partially implemented, and was not considered during design of much of the more modern toolchain detection logic.

The "language_support" attachments use an approach like what CMake itself uses to decide whether to enable Fortran tests:

 http://www.cmake.org/gitweb?p=cmake.git;a=blob;f=Tests/CheckFortran.cmake;hb=v3.1.2 [^]

This is much like a try_compile check, and is the best approach available right now.
(0037958)
Brad King (manager)
2015-02-12 08:35

 Relevant mailing list discussion thread:

 Fortran detection, issue 9220
 http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/12327 [^]
(0041575)
Kitware Robot (administrator)
2016-06-10 14:27

 Resolving issue as `moved`.

This issue tracker is no longer used. Further discussion of this issue may take place in the current CMake Issues page linked in the banner at the top of this page.

 Issue History
Date Modified Username Field Change
2009-06-29 18:33 Alan W. Irwin New Issue
2009-06-29 19:45 Alan W. Irwin Note Added: 0016780
2009-06-30 12:58 Alex Neundorf Status new => assigned
2009-06-30 12:58 Alex Neundorf Assigned To => Alex Neundorf
2009-07-16 19:45 Alan W. Irwin File Added: language_support.cmake
2009-07-16 19:52 Alan W. Irwin Note Added: 0016887
2009-08-22 22:22 Greg Sharp Note Added: 0017180
2009-08-22 22:23 Greg Sharp File Added: language_support_v2.cmake
2009-08-22 22:34 Greg Sharp Note Added: 0017181
2009-08-22 23:09 Greg Sharp Note Edited: 0017180
2009-08-22 23:09 Greg Sharp Note Deleted: 0017181
2009-08-22 23:09 Greg Sharp Note Edited: 0017180
2009-08-22 23:10 Greg Sharp Note Edited: 0017180
2009-11-25 18:13 Marcel Loose Note Added: 0018597
2009-11-27 04:00 Marcel Loose Note Added: 0018600
2010-06-18 12:51 David Cole Summary enable_language(.... OPTIONAL) signature does not work correctly => enable_language(.... OPTIONAL) signature does not work correctly
2011-04-14 14:28 David Cole Target Version => CMake 2.8.5
2011-05-25 16:59 David Cole Note Added: 0026593
2011-05-25 16:59 David Cole Target Version CMake 2.8.5 =>
2011-08-01 11:32 David Cole Assigned To Alex Neundorf => David Cole
2011-08-01 11:32 David Cole Target Version => CMake 2.8.6
2011-09-22 16:56 David Cole Note Added: 0027476
2011-09-22 16:56 David Cole Target Version CMake 2.8.6 =>
2012-05-18 10:12 sleske Note Added: 0029507
2012-05-18 10:39 sleske Note Added: 0029510
2012-05-21 08:20 Marcel Loose Note Added: 0029517
2012-05-21 15:06 sleske Note Added: 0029533
2012-10-15 11:31 David Cole Relationship added related to 0010227
2012-10-15 11:32 David Cole Relationship added related to 0008345
2012-11-21 14:57 David Cole Note Added: 0031650
2012-11-21 14:58 David Cole Assigned To David Cole =>
2012-11-21 15:11 David Cole Status assigned => new
2012-11-21 15:11 David Cole Note Added: 0031671
2014-09-10 16:36 sleske Note Edited: 0029533
2015-02-06 14:15 Brad King Note Added: 0037940
2015-02-12 08:35 Brad King Note Added: 0037958
2016-06-10 14:27 Kitware Robot Note Added: 0041575
2016-06-10 14:27 Kitware Robot Status new => resolved
2016-06-10 14:27 Kitware Robot Resolution open => moved
2016-06-10 14:27 Kitware Robot Assigned To => Kitware Robot
2016-06-10 14:30 Kitware Robot Status resolved => closed

Copyright © 2000 - 2018 MantisBT Team