[Flang = llvm-project/flang]
I have been trying to use Flang with CMake and this integration seems to be dysfunctional right now. Has anyone been using/testing it?
*How to test*
mkdir build && cd build
cmake -G Ninja -DCMAKE_Fortran_COMPILER=<path-to-flang-or-gfortran> ../
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:
If I understand correctly, CMake fails to identify Flang because the driver does not define the following preprocessor variables currently expected by CMake :
These macros were first discussed and added in , but then deleted in  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?
 Modules/CMakeFortranCompilerId.F.in · master · CMake / CMake · GitLab
 ⚙ D84334 [flang] Version information in flang/f18
 ⚙ D94422 [flang][driver] Unify f18_version.h.in and Version.inc.in
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:
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,  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 .
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.
These upper-case predefinitions were added to CMake long before LLVM Flang . 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 
 Add support for Flang (!1141) · Merge requests · CMake / CMake · GitLab
These upper-case predefinitions were added to CMake long before LLVM
Flang . I think that it is safe to assume that they were meant for
"classic Flang" rather than LLVM Flang.
The repository linked in  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
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
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.