# Gfortran and .smod files

**URL:** <https://fortran-lang.discourse.group/t/gfortran-and-smod-files/6909>\
**Category:** Uncategorized\
**Created:** [December 3, 2023, 3:12pm UTC](https://fortran-lang.discourse.group/t/gfortran-and-smod-files/6909 "2023-12-03T15:12:14Z")\
**Posts on this page:** 15\
**Page:** 1

<div class="post-metadata">

**Author:** ![rhtownsend](https://avatars.discourse-cdn.com/v4/letter/r/439d5e/32.png) [@rhtownsend](https://fortran-lang.discourse.group/u/rhtownsend)\
**Post date:** [December 3, 2023, 3:12pm UTC](https://fortran-lang.discourse.group/t/gfortran-and-smod-files/6909/1 "2023-12-03T15:12:14Z")

</div>

I’ve recently noticed that gfortran (13.1.0) seems to be creating many .smod files when compiling a big project. I don’t recall this being the case in the past, and this project doesn’t contain any submodules. Can anyone share insights into why these files are being generated – and should they play any role in the dependencies in my makefile?

---

<div class="post-metadata">

**Author:** ![gWyche](https://avatars.discourse-cdn.com/v4/letter/g/f6c823/32.png) [@gWyche](https://fortran-lang.discourse.group/u/gWyche)\
**Post date:** [December 19, 2023, 10:44pm UTC](https://fortran-lang.discourse.group/t/gfortran-and-smod-files/6909/2 "2023-12-19T22:44:00Z")

</div>

me, too with gFortran 10.2  
I just started with SUBMODULEs and only have file to create a generic for m\_c() and indeed my …mod/ has  
m\_c\_mod.smod and m\_c\_mod@m\_c\_funcs/smod

However, there are 7 more .smod

What is that about?

---

<div class="post-metadata">

**Author:** ![ivanpribec](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/ivanpribec/32/3290_2.png) [@ivanpribec](https://fortran-lang.discourse.group/u/ivanpribec)\
**Post date:** [December 20, 2023, 12:37am UTC](https://fortran-lang.discourse.group/t/gfortran-and-smod-files/6909/3 "2023-12-20T00:37:03Z")

</div>

> [@rhtownsend](#):
>
> Can anyone share insights into why these files are being generated

> **[Doctor Fortran in "We All Live in a Yellow Submodule" - Doctor Fortran](https://stevelionel.com/drfortran/2015/07/07/doctor-fortran-in-we-all-live-in-a-yellow-submodule/)**
>
> Fortran 90 introduced the concept of modules, a separately compiled collection of declarations and procedures that could be referenced by other program units. This was borrowed from Ada, (and probably other languages), but omitted one very...

> [@rhtownsend](#):
>
> and this project doesn’t contain any submodules.

Maybe a dependency of the project contains them, and they were fetched using CMake, fpm, or some other custom script?

> [@rhtownsend](#):
>
> and should they play any role in the dependencies in my makefile?

Yes. Submodule depends on the parent modules.

For example if you have:

```fortran
! foo.f90
module foo
   interface
      module subroutine hello()
      end subroutine
   end interface
end module

```

```fortran
! foo_sm.f90
submodule (foo) foo_sm
contains
   module procedure hello
      print *, "hello from a submodule"
   end procedure
end submodule

```

your Makefile should probably contain at least:

```txt
foo.o: foo.f90
   $(FC) $(FCFLAGS) -c $< 

foo_sm.o: foo_sm.f90
   $(FC) $(FCFLAGS) -c $< 

# Submodule depends on parent module
foo_sm.o: foo.o

```

With gfortran at least, compiling `foo.f90` will generate three files, `foo.o`, `foo.mod`, and `foo.smod`. Compiling the submodule, `foo_sm.o` and `foo@foo_sm.smod` are created.

---

<div class="post-metadata">

**Author:** ![everythingfunctional](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/everythingfunctional/32/176_2.png) [@everythingfunctional](https://fortran-lang.discourse.group/u/everythingfunctional)\
**Post date:** [December 20, 2023, 2:04pm UTC](https://fortran-lang.discourse.group/t/gfortran-and-smod-files/6909/4 "2023-12-20T14:04:23Z")

</div>

It is valid (albeit usually useless) to define a submodule even if there is nothing in the module implying that one would need to exist. I.e.

```auto
module mod
  implicit none
  private
  public :: const
  integer, const = 42
end module

```

```auto
submodule(mod) submod
    implicit none
contains
  subroutine show_it() bind(C)
    print *, const
  end subroutine
end submodule

```

```C
extern void show_it();
int main() {
  show_it();
}

```

And so the dependencies for such a project would look something like

```make
mod.o: mod.f90
mod.mod: mod.f90
mod.smod: mod.f90
submod.o: submod.f90 mod.smod
mod@submod.smod: submod.f90 mod.smod
main.o: main.c
main: main.o mod.o submod.o

```

---

<div class="post-metadata">

**Author:** ![ashe](https://avatars.discourse-cdn.com/v4/letter/a/ce73a5/32.png) [@ashe](https://fortran-lang.discourse.group/u/ashe)\
**Post date:** [December 20, 2023, 2:50pm UTC](https://fortran-lang.discourse.group/t/gfortran-and-smod-files/6909/5 "2023-12-20T14:50:59Z")

</div>

> [@everythingfunctional](#):
>
> It is valid (albeit usually useless) to define a submodule even if there is nothing in the module implying that one would need to exist.

I don’t think that’s true. C1412 (of Fortran 2018) says:

> The ancestor-module-name shall be the name of a nonintrinsic module that declares a separate module procedure

And with your example, I get this error from gfortran 12.2.0:

> f951: Fatal Error: Module file ‘mod.smod’ has not been generated, either because the module does not contain a MODULE PROCEDURE or there is an error in the module.

This might help explain why gfortran generates `.smod` files even when there are no submodules. There seems to be a `.smod` generated for modules that **can** have submodules so gfortran can perform that check.

---

<div class="post-metadata">

**Author:** ![msz59](https://avatars.discourse-cdn.com/v4/letter/m/3d9bf3/32.png) [@msz59](https://fortran-lang.discourse.group/u/msz59)\
**Post date:** [December 20, 2023, 3:15pm UTC](https://fortran-lang.discourse.group/t/gfortran-and-smod-files/6909/6 "2023-12-20T15:15:32Z")

</div>

> [@everythingfunctional](#):
>
> ```auto
> module mod
> implicit none
> private
> public :: const
> integer, const = 42
> end module
> 
> ```

How could you check that code if it is invalid? 🙂  
The last declaration should read `integer :: const = 42`

But more seriously. If there is no `module procedure` in the master module, no `.smod` file is generated by `gfortran`, either 12.2.0 or 13.2.0. So this claim:

> [@ashe](#):
>
> This might help explain why gfortran generates `.smod` files even when there are no submodules.

does not seem to hold.

```plaintext
$ gfortran-13 -c mod.f90 # corrected code :)
$ ls mod*
mod.f90 mod.mod mod.o

```

---

<div class="post-metadata">

**Author:** ![everythingfunctional](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/everythingfunctional/32/176_2.png) [@everythingfunctional](https://fortran-lang.discourse.group/u/everythingfunctional)\
**Post date:** [December 20, 2023, 4:00pm UTC](https://fortran-lang.discourse.group/t/gfortran-and-smod-files/6909/7 "2023-12-20T16:00:37Z")

</div>

> [@msz59](#):
>
> How could you check that code if it is invalid? 🙂

My mental compiler failed me there, missed the `parameter ::` part. I.e.

```auto
module mod
  implicit none
  private
  public :: const
  integer, parameter :: const = 42
end module

```

> [@ashe](#):
>
> C1412 (of Fortran 2018) says:
> 
> > The ancestor-module-name shall be the name of a nonintrinsic module that declares a separate module procedure

This one applies to my example too:

> C1807 A procedure defined in a submodule shall not have a binding label unless its interface is declared in the ancestor module.

But, the following example would satisfy the constraints, though it would be useless.

```auto
module mod
  interface
    module subroutine foo
    end subroutine
  end interface
contains
  module procedure foo
  end procedure
end module

```

```auto
submodule(mod) submod
contains
  subroutine unreachable
  end subroutine
end submodule

```

---

<div class="post-metadata">

**Author:** ![ashe](https://avatars.discourse-cdn.com/v4/letter/a/ce73a5/32.png) [@ashe](https://fortran-lang.discourse.group/u/ashe)\
**Post date:** [December 20, 2023, 8:06pm UTC](https://fortran-lang.discourse.group/t/gfortran-and-smod-files/6909/8 "2023-12-20T20:06:42Z")

</div>

> [@msz59](#):
>
> > [@ashe](#):
> >
> > This might help explain why gfortran generates `.smod` files even when there are no submodules.
> 
> does not seem to hold.
> 
> ```auto
> $ gfortran-13 -c mod.f90 # corrected code :)
> $ ls mod*
> mod.f90 mod.mod mod.o
> 
> ```

I didn’t mean to imply that a `.smod` was generated for every module, just that it can happen regardless of whether submodules are present. For example:

```auto
$ cat mod.f90
module mod
  interface
    module subroutine foo
    end subroutine
  end interface
end module
$ gfortran -c mod.f90
$ ls mod*
mod.f90 mod.mod mod.o mod.smod

```

---

<div class="post-metadata">

**Author:** ![msz59](https://avatars.discourse-cdn.com/v4/letter/m/3d9bf3/32.png) [@msz59](https://fortran-lang.discourse.group/u/msz59)\
**Post date:** [December 20, 2023, 9:28pm UTC](https://fortran-lang.discourse.group/t/gfortran-and-smod-files/6909/9 "2023-12-20T21:28:06Z")

</div>

Well, but with such a module interface containing “module subroutine” which is not defined in the module itself, **requires** a submodule to be present (eventually, in order to build working executable). Also, if `foo` were defined in the module `mod`, the interface would not be needed at all.

---

<div class="post-metadata">

**Author:** ![ivanpribec](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/ivanpribec/32/3290_2.png) [@ivanpribec](https://fortran-lang.discourse.group/u/ivanpribec)\
**Post date:** [December 20, 2023, 11:00pm UTC](https://fortran-lang.discourse.group/t/gfortran-and-smod-files/6909/10 "2023-12-20T23:00:37Z")

</div>

> [@everythingfunctional](#):
>
> And so the dependencies for such a project would look something like
> 
> ```auto
> mod.o: mod.f90
> mod.mod: mod.f90
> mod.smod: mod.f90
> submod.o: submod.f90 mod.smod
> mod@submod.smod: submod.f90 mod.smod
> main.o: main.c
> main: main.o mod.o submod.o
> 
> ```

Do you know if CMake also encodes dependencies between module and submodules this way when generating Makefiles?

A few times I’ve tried to use [multiple targets](https://www.gnu.org/software/make/manual/html_node/Multiple-Targets.html) in Make rules:

```txt
mod.o mod.mod mod.smod: mod.f90
submod.o mod@submod.smod: submod.f90 mod.smod
main: main.c mod.o submod.o

```

It quickly becomes unreadable if you have directories involved, or if you want the modules to be placed elsewhere (out-of-source build). Also the labor of tracking which files contains modules, submodules, programs, or external procedures is tedious and unrewarding.

For small projects I still do it sometimes, but once I reach about ten files or recognize that more configuration is needed, or that third-party dependencies will be used, I usually switch over to CMake.

---

<div class="post-metadata">

**Author:** ![everythingfunctional](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/everythingfunctional/32/176_2.png) [@everythingfunctional](https://fortran-lang.discourse.group/u/everythingfunctional)\
**Post date:** [December 21, 2023, 12:07am UTC](https://fortran-lang.discourse.group/t/gfortran-and-smod-files/6909/11 "2023-12-21T00:07:29Z")

</div>

> [@ivanpribec](#):
>
> Do you know if CMake also encodes dependencies between module and submodules this way when generating Makefiles?

I’m not sure. I abandoned Make when it seemed like it didn’t support multiple targets in a rule (I know now that it does), and rather than learn CMake decided to write my own. I had one that used Rake and Ruby at one point, then that used Shake and Haskell, which eventually made its way into the initial implementation of fpm.

---

<div class="post-metadata">

**Author:** ![ivanpribec](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/ivanpribec/32/3290_2.png) [@ivanpribec](https://fortran-lang.discourse.group/u/ivanpribec)\
**Post date:** [December 21, 2023, 8:34am UTC](https://fortran-lang.discourse.group/t/gfortran-and-smod-files/6909/12 "2023-12-21T08:34:41Z")

</div>

I though it would be instructive to see how [Ninja](https://ninja-build.org/manual.html) approaches the module dependency situation, as one of the CMake backends.

For Brad’s example,

```fortran
! mod.f90
module mod
  implicit none
  private
  public :: const, show_it
  interface
    module subroutine show_it() bind(c)
    end subroutine
  end interface
  integer, parameter :: const = 42
end module

```

```fortran
! submod.f90
submodule(mod) submod
    implicit none
contains
  subroutine show_it() bind(C)
    print *, const
  end subroutine
end submodule

```

```c
// main.c
extern void show_it();
int main() {
  show_it();
}

```

the Ninja build script would look as follows:

```txt
# build.ninja
ninja_required_version = 1.1

fflags = -Wall
cflags = -Wall

fc=gfortran-13
cc=gcc-13

# Rule declarations
rule fcompile
    command = $fc $fflags -o $out -c $in
rule ccompile
    command = $cc $cflags -o $out $in -lgfortran

# Build edges
build mod.o: fcompile mod.f90 || graph.dd
    dyndep = graph.dd
build submod.o: fcompile submod.f90 || graph.dd
    dyndep = graph.dd
build main: ccompile main.c mod.o submod.o

default main

```

```txt
# graph.dd
ninja_dyndep_version = 1
build mod.o | mod.mod mod.smod: dyndep
build submod.o | mod@submod.smod: dyndep | mod.smod 

```

In practice the `graph.dd` file would be generated by a [`fscan`](https://ninja-build.org/manual.html#_fortran_modules) tool that would analyze the source tree for modules and dependencies between them in a preliminary pass. This is what CMake does, and I think a ninja backend for fpm would be a great project. I suppose one could also try to modify [`makedepf90`](https://linux.die.net/man/1/makedepf90) (but it’s missing submodule parsing, and probably lacks a few other things), [FF08Depends](https://www.megms.com.au/ff08depends.htm) by Ian Harvey, or LFortran. Having this built in to the compiler would be ideal though (no need to install two separate tools).

The ninja tool is then invoked as follows:

```txt
/ninja_test$ ninja -v # -v for verbose output
[1/3] gfortran-13 -Wall -o mod.o -c mod.f90
[2/3] gfortran-13 -Wall -o submod.o -c submod.f90
[3/3] gcc-13 -Wall -o main main.c mod.o submod.o -lgfortran

```

---

<div class="post-metadata">

**Author:** ![msz59](https://avatars.discourse-cdn.com/v4/letter/m/3d9bf3/32.png) [@msz59](https://fortran-lang.discourse.group/u/msz59)\
**Post date:** [December 23, 2023, 9:24pm UTC](https://fortran-lang.discourse.group/t/gfortran-and-smod-files/6909/13 "2023-12-23T21:24:46Z")

</div>

Don’t you think the whole system would be easier to maintain if `.(s)mod` filenames started always with the basename (minus ext) of the source file name where the (sub)modules are defined? Say, `mod2.f90` file with `amod` and `bmod` modules and `bsub` submodule to `bmod` would generate `mod2@amod.mod`, `mod2@bmod.mod`, `mod2@bmod.smod` and `mod2@bmod@bsub.smod`.

---

<div class="post-metadata">

**Author:** ![ashe](https://avatars.discourse-cdn.com/v4/letter/a/ce73a5/32.png) [@ashe](https://fortran-lang.discourse.group/u/ashe)\
**Post date:** [December 25, 2023, 7:50pm UTC](https://fortran-lang.discourse.group/t/gfortran-and-smod-files/6909/14 "2023-12-25T19:50:44Z")

</div>

I think that would make it harder for the compiler when it’s processing USE statements. When the compiler sees `use foo` it looks for for `foo.mod` to get information about the module. If the `.mod` file name was based on the source file name, any `.mod` file could be the one needed.

---

<div class="post-metadata">

**Author:** ![nja](https://avatars.discourse-cdn.com/v4/letter/n/ed8c4c/32.png) [@nja](https://fortran-lang.discourse.group/u/nja)\
**Post date:** [December 26, 2023, 12:40pm UTC](https://fortran-lang.discourse.group/t/gfortran-and-smod-files/6909/15 "2023-12-26T12:40:43Z")

</div>

Yes, keep in mind that the module name and file name can be different, plus, one file can define several modules (I don’t say it’s a good idea, but it’s allowed).