# Build fails with Fortran modules nammed with macros

**URL:** https://discourse.cmake.org/t/build-fails-with-fortran-modules-nammed-with-macros/1595
**Category:** Usage
**Created:** [July 20, 2020, 9:24pm UTC](https://discourse.cmake.org/t/build-fails-with-fortran-modules-nammed-with-macros/1595 "2020-07-20T21:24:13Z")
**Posts on this page:** 7
**Page:** 1

<div class="post-metadata">

### Author: ![sgilbertjob](https://discourse.cmake.org/letter_avatar_proxy/v4/letter/s/3be4f8/32.png) [@sgilbertjob](https://discourse.cmake.org/u/sgilbertjob)
#### Post date: [July 20, 2020, 9:24pm UTC](https://discourse.cmake.org/t/build-fails-with-fortran-modules-nammed-with-macros/1595/1 "2020-07-20T21:24:14Z")

</div>

Hello,

I am working on a Fortran project that simulates generic programming (or C++ type templates) with include files and macros. We have decided to replace our home-brew build system with CMake and, up to now, things have went pretty well.

I have made a really small example that shows the issue we are running into. It’s made up of 4 files:

square.inc:

```
module GEN_NAME(trigo_)
    implicit none
    contains

    DATATYPE function square(num)
        implicit none
        DATATYPE, intent(in) :: num
        square = num * num
    end function
end module

```

square.F90

```
#define DATATYPE integer
#define GEN_NAME(name) name/**/integer
#include "square.inc"
#undef GEN_NAME
#undef DATATYPE

#define DATATYPE real
#define GEN_NAME(name) name/**/real
#include "square.inc"
#undef GEN_NAME
#undef DATATYPE

```

main.F90

```
program main
    use trigo_real
    implicit none
    real, parameter :: py = 3.1416
    print *, 'I make square pies: ', square(py)
end program

```

CMakeLists.txt

```
cmake_minimum_required(VERSION 3.16)
project(test_generic_f90 LANGUAGES Fortran)
file(GLOB PROJECT_F_FILES *.F90)
add_executable(main ${PROJECT_F_FILES})

```

Building manually work fine:

```
gfortran -c square.F90
gfortran -o main main.F90 square.o

```

However, if I try to build this project with CMake, I get the following error:

`Error copying Fortran module "gen_name.mod". Tried "GEN_NAME.mod" and "gen_name.mod".`

It looks like CMake did not parse the macro to get the actual module name since I still see “GEN\_NAME.mod” instead of “trigo\_integer.mod” or"trigo\_real.mod".

Is there a way I can fix this in my project or does it require changes in CMake?

Cheers!

---

<div class="post-metadata">

### Author: ![ben.boeckel](https://discourse.cmake.org/letter_avatar_proxy/v4/letter/b/ea5d25/32.png) [@ben.boeckel](https://discourse.cmake.org/u/ben.boeckel)
#### Post date: [November 11, 2020, 5:24pm UTC](https://discourse.cmake.org/t/build-fails-with-fortran-modules-nammed-with-macros/1595/2 "2020-11-11T17:24:56Z")

</div>

I suspect this is a gap in our Fortran support. I don’t know how much work it’d be to fix it. I suggest filing an issue with this example so we can at least track it.

Cc: @brad.king

---

<div class="post-metadata">

### Author: ![brad.king](https://discourse.cmake.org/user_avatar/discourse.cmake.org/brad.king/32/11_2.png) [@brad.king](https://discourse.cmake.org/u/brad.king)
#### Post date: [November 11, 2020, 8:01pm UTC](https://discourse.cmake.org/t/build-fails-with-fortran-modules-nammed-with-macros/1595/3 "2020-11-11T20:01:50Z")

</div>

With the Ninja generator, I’d expect this to work. It preprocesses using the real compiler before extracting module dependencies.

With the Makefile generators we use approximate preprocessing for dependency scanning, and it doesn’t expand macros. This approach predates the approach used by the Ninja generator. The Makefile generators will need updates to use the newer approach.

---

<div class="post-metadata">

### Author: ![Angew](https://discourse.cmake.org/user_avatar/discourse.cmake.org/angew/32/229_2.png) [@Angew](https://discourse.cmake.org/u/Angew)
#### Post date: [November 12, 2020, 10:23am UTC](https://discourse.cmake.org/t/build-fails-with-fortran-modules-nammed-with-macros/1595/4 "2020-11-12T10:23:40Z")

</div>

Please be aware that there are Fortran files out in the wild which do not function correctly if preprocessed (e.g. they use identifiers which clash with common macro names such as `DEBUG`); this is especially tricky in targets which mix C[++] and Fortran files.

When we switched from Make to Ninja, we had to work around this by adding the compilation flag `-Qoption,fpp,-macro=no` to such files. When modifying the automatic-Fortran-preprocessing implementation in CMake, please keep such a workaround possible.

---

<div class="post-metadata">

### Author: ![ben.boeckel](https://discourse.cmake.org/letter_avatar_proxy/v4/letter/b/ea5d25/32.png) [@ben.boeckel](https://discourse.cmake.org/u/ben.boeckel)
#### Post date: [November 12, 2020, 12:14pm UTC](https://discourse.cmake.org/t/build-fails-with-fortran-modules-nammed-with-macros/1595/5 "2020-11-12T12:14:23Z")

</div>

There is support for not compiling the preprocessed source now. See [this MR](https://gitlab.kitware.com/cmake/cmake/merge_requests/4659) which is in 3.18.0. I believe that scanning still requires preprocessing in Ninja though.

---

<div class="post-metadata">

### Author: ![brad.king](https://discourse.cmake.org/user_avatar/discourse.cmake.org/brad.king/32/11_2.png) [@brad.king](https://discourse.cmake.org/u/brad.king)
#### Post date: [November 12, 2020, 1:10pm UTC](https://discourse.cmake.org/t/build-fails-with-fortran-modules-nammed-with-macros/1595/6 "2020-11-12T13:10:46Z")

</div>

That same merge request also taught the Ninja generator to _not_ run preprocessing before scanning when the [Fortran\_PREPROCESS](https://cmake.org/cmake/help/latest/prop_tgt/Fortran_PREPROCESS.html) property is off.

---

<div class="post-metadata">

### Author: ![Angew](https://discourse.cmake.org/user_avatar/discourse.cmake.org/angew/32/229_2.png) [@Angew](https://discourse.cmake.org/u/Angew)
#### Post date: [November 12, 2020, 1:13pm UTC](https://discourse.cmake.org/t/build-fails-with-fortran-modules-nammed-with-macros/1595/7 "2020-11-12T13:13:05Z")

</div>

Thanks for the info. I somehow missed this when reading 3.18 release notes. We’re still at 3.14 at work, but I can add this to the pile of “reasons to upgrade.”