[CMake] mixing c/fortran - missing gfortran sometimes
Brad King
brad.king at kitware.com
Fri Sep 24 08:25:08 EDT 2010
On 09/24/2010 12:40 AM, Clinton Stimpson wrote:
> If I have these two cmake files
> === CMakeLists.txt
> project(prj)
> add_subdirectory(sub)
> add_executable(main main.cpp)
> target_link_libraries(main sub)
> ===
>
> === sub/CMakeLists.txt
> project(sub C Fortran)
> add_library(sub hello.f hello2.c)
> ===
>
> I get link errors. If I change the first to have
> project(prj C CXX Fortran)
> or add an enable_language(Fortran)
> then the problem goes away.
Interesting. Thanks for the small example.
> So does this basically mean the parent cmake files have to know what
> languages are being used?
Internally CMake keeps track of the list of languages compiled into
each library. When computing link dependencies CMake propagates the
transitive closure of all the languages used. From that it chooses
one language to drive the link and then adds the implicit libraries
from other languages not already known to be provided by the first.
I think what happens in your example is that when linking "main"
CMake says
"I need to use the C++ front-end to link and pass the
Fortran libraries implicitly."
So far so good. Then it says
"What are the implicit Fortran libraries? Well, in the CMakeLists.txt
file where this target (main) is linking, the value of
CMAKE_Fortran_IMPLICIT_LINK_LIBRARIES is empty so there must be no
implicit libraries."
Clearly this is a bug. The work around is to enable all languages at
the top level, as you discovered, to be sure the list of implicit
libraries is available everywhere.
I need to think more about how to fix this bug. The problem is deeper
than just the implicit libraries. If CMake were to choose Fortran as
the linker language at the top level (perhaps if it were C only up there
but linked to a Fortran library from a subdirectory), then it would
not be able to find the link rules.
-Brad
More information about the CMake
mailing list