[Flang = llvm-project/flang]
Hello,
I have been trying to use Flang with CMake and this integration seems to be dysfunctional right now. Has anyone been using/testing it?
*Minimal reproducer*
project(hello_fortran Fortran)
add_executable(hello hello.f90)
*How to test*
mkdir build && cd build
cmake -G Ninja -DCMAKE_Fortran_COMPILER=<path-to-flang-or-gfortran> ../
*The error*
My minimal reproducer works fine with `gfortran`, but it fails with `flang`:
CMake Error: Error required internal CMake variable not set, cmake may not be built correctly.
Missing variable is:
CMAKE_Fortran_PREPROCESS_SOURCE
If I understand correctly, CMake fails to identify Flang because the driver does not define the following preprocessor variables currently expected by CMake [1]:
* __FLANG
* __FLANG_MAJOR__
* __FLANG_MINOR__
These macros were first discussed and added in [2], but then deleted in [3] in order to keep Flang consistent with the rest of LLVM.
This seems to have been broken for a while, so I suspect that this has not been required by anyone recently?
Thank you,
-Andrzej
[1] Modules/CMakeFortranCompilerId.F.in · master · CMake / CMake · GitLab
[2] ⚙ D84334 [flang] Version information in flang/f18
[3] ⚙ D94422 [flang][driver] Unify f18_version.h.in and Version.inc.in
Andrzej,
Thanks for raising awareness of the program.
I think someone will need to add support for Flang in CMake. I don’t have a good sense of who big of a project that will be. This is what Intel had to do for the new LLVM-based compiler:
https://gitlab.kitware.com/cmake/cmake/-/merge_requests/5594
I am not sure if there is a quick hack for it, the merged request above for the Intel LLVM-based compiler was a good chunk of CMake code.
If I understand correctly, [3] only renamed __FLANG_MAJOR__ to
FLANG_VERSION_MAJOR_STRING in its own internal configuration. This
name is not discoverable by invoking flang. Instead, flang's
preprocessor defines `__flang__`, `__flang_major__`, `__flang_minor__`
and `__flang_patchlevel__` which have not changed in [3].
Maybe CMake checks the upper case versions because classic flang sets
them? In any case, CMake should work with any unknown fortran
compiler, so you could file a bug with CMake.
Michael
These upper-case predefinitions were added to CMake long before LLVM Flang [1]. I think that it is safe to assume that they were meant for "classic Flang" rather than LLVM Flang.
`__flang__`, `__flang_major__`, `__flang_minor__` and `__flang_patchlevel__` are defined by the driver rather then the preprocessor. These pre-definitions are consistent with Clang.
@Nick, thank you for sending that link! It looks like a non-trivial amount of effort. I wonder whether there are any low hanging fruits for us?
@Michael, clearly LLVM Flang and CMake are currently out-of-sync and I guess that we should be pro-active about these things? Btw, I authored [3] 
-Andrzej
[1] Add support for Flang (!1141) · Merge requests · CMake / CMake · GitLab
These upper-case predefinitions were added to CMake long before LLVM
Flang [1]. I think that it is safe to assume that they were meant for
"classic Flang" rather than LLVM Flang.
The repository linked in [1] is classic flang.
`__flang__`, `__flang_major__`, `__flang_minor__` and
`__flang_patchlevel__` are defined by the driver rather then the
preprocessor. These pre-definitions are consistent with Clang.
From the programmer's perspective there is no difference which
component defines a macro. They are expanded the same in CMake's
introspection program.
From what I have seen it seems to me that there is no version of new
flang/f18 that defined a __FLANG_MAJOR__ etc. preprocessor macro
itself. Is this wrong?
What additional macros does the preprocessor define?
Which macros should CMake use to detect new flang/f18 and distinguish
it from classic flang?
The CMake maintainers are quite responsive and have an interest in
making flang work due their involvement in ECP. I suggest to open a
bug report in the CMake bug tracker to coordinate above questions with
them.
Michael
Are we now able to clearly distinguish classic flang vs. flang with preprocessor macros?
I think that would be a pre-requisite before filing a bug report/feature request with the CMake team.
It is good to hear that they are engaged because of their involvement with ECP.