# Automatic Make recipes generation **URL:** \ **Category:** Announcements\ **Created:** [December 24, 2025, 9:03pm UTC](https://fortran-lang.discourse.group/t/automatic-make-recipes-generation/10570 "2025-12-24T21:03:24Z")\ **Posts on this page:** 18\ **Page:** 1
**Author:** ![lsmenicucci](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/lsmenicucci/32/4817_2.png) [@lsmenicucci](https://fortran-lang.discourse.group/u/lsmenicucci)\ **Post date:** [December 24, 2025, 9:03pm UTC](https://fortran-lang.discourse.group/t/automatic-make-recipes-generation/10570/1 "2025-12-24T21:03:24Z")
I would like to announce a small tool which extract the module/submodule declaration and dependencies across multiple Fortran sources and generates recipes to be used in Makefiles. Here is a sample output: ```auto $ mk-fdeps test/basic/**/*.f90 --include-targets build/basic/b.o: build/basic/a.o build/basic/c.o: build/basic/a.o build/basic/b.o build/basic/d.o: build/basic/b.o build/basic/e.o: build/basic/a.o build/basic/c.o build/basic/subdir/d.o: build/basic/b.o build/basic/c: build/basic/c.o build/basic/a.o build/basic/b.o build/basic/d: build/basic/d.o build/basic/b.o build/basic/e: build/basic/e.o build/basic/a.o build/basic/c.o ``` So they can be included like: ```makefile FC=gfortran FC_FLAGS=-O0 -g -fbounds-check -Jbuild build: mkdir -p $@ build/%.o: %.f90 | build $(FC) $(FC_FLAGS) -c $^ -o $@ build/%: | build $(FC) $(FC_FLAGS) $^ -o $@ # import generated recipes include ./deps.mk ``` It is currently capable of parsing code in free format and supports preprocessing. I haven’t tested it in large codebases, any feedback is appreciated. Here is the repository link for more details: [GitHub - lsmenicucci/mk-fdeps](https://github.com/lsmenicucci/mk-fdeps) ---
**Author:** ![gronki](https://avatars.discourse-cdn.com/v4/letter/g/a88e4f/32.png) [@gronki](https://fortran-lang.discourse.group/u/gronki)\ **Post date:** [December 25, 2025, 2:17pm UTC](https://fortran-lang.discourse.group/t/automatic-make-recipes-generation/10570/2 "2025-12-25T14:17:59Z")
Great work! I have done something similar years ago, although it is now unmaintained and probably will not run: [GitHub - gronki/fortdep: A script for generating dependencies between Fortran modules for make](https://github.com/gronki/fortdep) ---
**Author:** ![gardhor](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/gardhor/32/88_2.png) [@gardhor](https://fortran-lang.discourse.group/u/gardhor)\ **Post date:** [December 26, 2025, 9:43am UTC](https://fortran-lang.discourse.group/t/automatic-make-recipes-generation/10570/3 "2025-12-26T09:43:11Z")
Nice work! I’ve try to use it with my code and I’ve found some issues. One is easy to solve: - The keywords (use, module, submodule …) should be case insensitive. I’ll make a pull request to fix that. - In my codes, the object and module files (.o and .mod) are stored in a specific directory. I’ve managed to use “–with-parent”, ~~but cannot remove the path of the tree source files (I’ve tried with “–strip-parents” without success).~~ I’ve managed to use correctly “–strip-parents”. Finally, my code can be compiled with the dependencies generated with your code. ---
**Author:** ![certik](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/certik/32/4_2.png) [@certik](https://fortran-lang.discourse.group/u/certik)\ **Post date:** [December 26, 2025, 4:51pm UTC](https://fortran-lang.discourse.group/t/automatic-make-recipes-generation/10570/4 "2025-12-26T16:51:56Z")
@lsmenicucci nice, I see you used Fortran to implement it! If you wanted, you could help us fix this issue in fpm: [Have CMake and Make backends · Issue #69 · fortran-lang/fpm · GitHub](https://github.com/fortran-lang/fpm/issues/69) to generate Makefiles for any fpm project, with dependencies, automatically. If your project would work with fpm, then you could just make fpm spit out makefiles and use make as you do with `mk-fdeps`. ---
**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:** [January 4, 2026, 7:46pm UTC](https://fortran-lang.discourse.group/t/automatic-make-recipes-generation/10570/5 "2026-01-04T19:46:59Z")
Great work! This is a very worthwhile project. It would be a nice project to expose the **fpm** module scanner as a Make target dependency generator, or vice-versa, allow **mk-fdeps** to be used from fpm. In fpm the module dependency scanning is accomplished here: [`fpm_source_parsing.f90`](https://github.com/fortran-lang/fpm/blob/a3324c2ddfcc8350b8b2b38d0f26dcbed98fad47/src/fpm_source_parsing.f90#L260) There is a long “tradition” of writing tools like [makedepend](https://en.wikipedia.org/wiki/Makedepend) or [mkdep](https://linux.die.net/man/1/mkdep). Major Make texts dedicate entire chapters to the use of such tools: - [R. Mecklenburg, Managing Projects with GNU Make, O’Reilly, 2004](https://www.oreilly.com/library/view/managing-projects-with/0596006101/) - [John Graham-Cumming, GNU Make Book, no starch press, 2015](https://nostarch.com/gnumake) The make dependency topic was a perennial topic on comp.lang.fortran in the 90s (when Fortran modules were introduced). It also pops up regularly here on Fortran Discourse. See some of my previous posts: - [CMake FortranCInterface - #8 by ivanpribec](https://fortran-lang.discourse.group/t/cmake-fortrancinterface/7573/8) - [Module dependencies - #9 by ivanpribec](https://fortran-lang.discourse.group/t/module-dependencies/1194/9) - [Ways to suppress Circularity - #5 by ivanpribec](https://fortran-lang.discourse.group/t/ways-to-suppress-circularity/8620/5) I’ve compiled a table of existing tools below (in no particular order) | Tool | Implemented in | Comment | | --- | --- | --- | | [makedepf90](https://github.com/outpaddling/makedepf90) | C, Lex | By Erik Edelmann from CSC (Finnish IT Center for Science) | | [fpt](https://simconglobal.com/fpt_ref_make_makefile.html) | Fortran | Commercial tool from [SimCon](https://www.simconglobal.com/) (by @Jcollins) | | [AUTOMAKE](https://fortran.uk/plusfortmanual/automake.html) | ? | From the PlusFORT toolkit (by @apple3feet) | | [mkmf](https://github.com/NOAA-GFDL/mkmf) | Perl | Developed at NOAA GFDL | | [makemake](https://web.phys.ntnu.no/~ingves/Teaching/TFY4235/Code/Download/makemake) | Perl | | | [makedepf08.awk](https://aoterodelaroza.github.io/devnotes/modern-fortran-makefiles/) | Awk | | | [gen-deps.awk](https://fortran-lang.org/learn/building_programs/project_make/#automatically-generated-dependencies) | Awk | Form the Fortran-lang Make tutorial | | [FF08Depends](https://www.megms.com.au/ff08depends.htm) | Fortran | By Ian Harvey | | [`ifx -gen-dep`](https://www.intel.com/content/www/us/en/docs/fortran-compiler/developer-guide-reference/2025-3/gen-dep.html) | ? | Built-in (Intel Fortran compiler) | | [`nagfor =depend`](https://support.nag.com/nagware/np/r71_doc/manual/compiler_2_22.html#DEPEND) | ? | Built-in (NAG compiler) | | [`ftnmgen`](https://cpe.ext.hpe.com/docs/24.11/cce/man1/ftnmgen.1.html) | ? | HPE Cray Compiler Environment | | [fdep](https://gitlab.mpcdf.mpg.de/elpa/elpa/-/tree/master/fdep) | Perl | From the ELPA project | | [fort\_depend.py](https://github.com/ZedThree/fort_depend.py) | Python | By @zedthree | | [run-fortran](https://github.com/lycantropos/run-fortran) | Python | | | [mkhelper](https://github.com/skosukhin/mkhelper) | Python, Shell | | | [fortdep](https://github.com/gronki/fortdep) | Python | By @gronki | | [f90\_mod\_deps.py](https://lagrange.mechse.illinois.edu/f90_mod_deps/) | Python | | | [fake](https://sourceforge.net/projects/fortranmake/) | Bash | | | [findent](https://www.ratrabbit.nl/ratrabbit/findent/index.html) | ? | Can also generate dependency information | | CMake | C++/C (?) | uses an extended version of makedepf90, more information [here](https://mathstuf.fedorapeople.org/fortran-modules/fortran-modules.html) | | fpm | Fortran | doesn’t expose Makefile target generation | | [`mk-fdeps`](https://github.com/lsmenicucci/mk-fdeps) | Fortran | Topic of this thread | | [FortranDep](https://github.com/irukoa/FortranDep) | C | Discourse Announcement (by @irukoa) : [A small, portable Fortran dependency generator (modules, submodules, and CPP includes)](https://fortran-lang.discourse.group/t/a-small-portable-fortran-dependency-generator-modules-submodules-and-cpp-includes/10892) | A couple more tools are listed at the Fortran Wiki [Build Tools](https://fortranwiki.org/fortran/show/Build+tools) page and @Beliavsky’s [Fortran Tools](https://github.com/Beliavsky/Fortran-Tools?tab=readme-ov-file#build-tools) list. guess that SCons and Meson also have their own Fortran module dependency scanners. AFAIK, IDEs like SimplyFortran and Code::Blocks (CBFortran?) also support Makefile generation. Many large Fortran projects (e.g. [CPMD](https://github.com/CPMD-code/CPMD/blob/eaeb1a977fabe570e7a4e2ca1dca53e8f360b054/scripts/configure.sh#L960)) still maintain custom scripts. It’s a bit of a tragedy that this has been re-invented so many times, likely due to a mix of [“Not Invented Here”](https://en.wikipedia.org/wiki/Not_invented_here) syndrome and also a historical lack of centralized tooling in the Fortran world. Most of these tools eventually struggle with the same issue, [as Brad King (Kitware) noted](https://gitlab.kitware.com/cmake/cmake/-/issues/18427#note_678640): > My concern with trying to parse the module function grammar is that it is huge and any partial implementation will inevitably run into cases it doesn’t handle and then the solution will be “just add this one little bit more” repeated over and over. Eventually the tools fall into disrepair or fail on newer features like submodules. In the same thread, but a different post, Brad King noted: > In the long term, I’d like to see Fortran compilers adopt the approach we’ve proposed for C++ module dependencies in [P1689r4](http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p1689r4.html). The situation in Fortran mirrors the C/UNIX world. As Eric Raymond writes in [TAOUP](http://www.catb.org/esr/writings/taoup/html/ch15s04.html), > Each different makefile generator tackles these objectives in a slightly different way. Probably a dozen or more generators have been attempted, but most proved inadequate or too difficult to drive or both, and only a few are still in live use. C++20 module dependencies are in a similar (broken?) state. Here is one view of the C++ module problems: [Nibble Stew: We need to seriously think about what to do with C++ modules](https://nibblestew.blogspot.com/2025/08/we-need-to-seriously-think-about-what.html) (HN discussion available [here](https://news.ycombinator.com/item?id=45086210)) Will we ever reach that “long-term” solution, where the module dependency scanners are flexible, robust, and widely available? What can we do differently as a community? ---
**Author:** ![urbanjost](https://avatars.discourse-cdn.com/v4/letter/u/0ea827/32.png) [@urbanjost](https://fortran-lang.discourse.group/u/urbanjost)\ **Post date:** [January 6, 2026, 8:08pm UTC](https://fortran-lang.discourse.group/t/automatic-make-recipes-generation/10570/6 "2026-01-06T20:08:57Z")
A number of compilers have options to generate the dependencies as well. ``` ifx -gen-dep=dep.mk -syntax_only *90 */*90 ``` complications always include handling cpp pre-processor directives and #include, recognizing intrinsics (making it a good rule to include the intrinsic descriptor in USE statements if anyone is keeping a “best practices” list; which makes that easy to add; as many vendors consider their proprietary libraries “intrinsics”, which is actually useful when figuring out what to exclude) plus what you already listed (“new” features such as submodules, …). Now that the fpm model is much more accessible and is becoming more powerful and flexible a plugin using the model dump or API from fpm seems the best place to concentrate community efforts; although fpm makes using make less and less necessary. The biggest think I miss about pre-module Fortran is being able to compile things in just about any order I wanted independently of other files. Maybe the only thing I miss, but that was nice. A standard format for _.mod files that could be included in a an archive (_.a) file or equivalent would sure be nice too. Your entry looks to me like a good mini-book for the fortran-lang site or an entry on the Fortran Wiki page. It would be nice if lists like this could be “starred” to indicate popularity and rated, perhaps like movies often are on “rotten-tomatoes” and similar sites. In the not too distant past is was very hard to obtain open-source Fortran modules and libraries; the good news is that more and more are appearing in the github/gitlab/… and fortran-lang/discourse/ Fortran/Wiki/ @Beliavsky lists such that it is getting very time-consuming to sort through them. Perhaps a good problem in some respects, but one that it would be nice to have addressed. ---
**Author:** ![urbanjost](https://avatars.discourse-cdn.com/v4/letter/u/0ea827/32.png) [@urbanjost](https://fortran-lang.discourse.group/u/urbanjost)\ **Post date:** [January 6, 2026, 9:03pm UTC](https://fortran-lang.discourse.group/t/automatic-make-recipes-generation/10570/7 "2026-01-06T21:03:01Z")
A particularly nice thing to me about your utility appears to go unmentioned. No additional infrastructure is required as it is written in Fortran. That has an appeal to this audience that should not be overlooked. If you also released it in a single-file format that just required a simple compile that would be an additional nicety. So many tools end up needing a large amount of infrastucture and a lot of Fortran developers often work on large platforms with limited access to the WWW or (because they are centrally administered, etc. …) the user cannot easily install additional tools. I think you should mention it is a Fortran-based solution on your site. If I am developing Fortran codes and all I need is the source and a Fortran compiler to add your tool (given how portable standard Fortran is) I have far less reasons to hesitate becoming dependent on it; and that audience is also more confident they can modify it or assume support of it in some distant future if support is dropped. Those are not inconsequential features for a lot of Fortran developers. ---
**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:** [January 7, 2026, 2:04am UTC](https://fortran-lang.discourse.group/t/automatic-make-recipes-generation/10570/8 "2026-01-07T02:04:19Z")
The HPE [Cray Compiler Environment](https://cpe.ext.hpe.com/docs/24.11/cce/index.html) also has its own Makefile generator: [`ftnmgen`](https://cpe.ext.hpe.com/docs/24.11/cce/man1/ftnmgen.1.html) One more for the table. * * * > [@urbanjost](#): > > The biggest think I miss about pre-module Fortran is being able to compile things in just about any order I wanted independently of other files. This is still true of submodules if I’m not mistaken. But the parent modules must be processed first. > [@urbanjost](#): > > A standard format for \*.mod files that could be included in a an archive (\*.a) file or equivalent would sure be nice too. This wouldn’t make much sense, as pointed out in the four replies starting here: [Containers using F202Y's generic programming - #29 by ashe](https://fortran-lang.discourse.group/t/containers-using-f202ys-generic-programming/10484/29). As Themos pointed out, even if the module format was shared, there is a realistic chance of incompatibilities in the runtime support library. It is similar to how you can’t do a `malloc` in C followed by a `deallocate` in Fortran. It wouldn’t work to have a object compiled with `gfortran` call `allocate`, and let the `deallocate` happen in an `ifx`-compiled object. The compilers use different array descriptors, different conventions, etc. > [@urbanjost](#): > > complications always include handling cpp pre-processor directives and #include Yep. Include files can be recursive, so one has to process them as they come. Also the tool will need to correctly mimic the compiler include folder search logic to resolve preprocessor symbols. ---
**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:** [January 7, 2026, 2:53am UTC](https://fortran-lang.discourse.group/t/automatic-make-recipes-generation/10570/9 "2026-01-07T02:53:02Z")
I can report that `mk-fdeps` can [**bootstrap**](https://en.wikipedia.org/wiki/Bootstrapping) it’s own Makefile. To test this I created a second makefile named `Makefile2`, containing the following notable changes: ```auto # Built with manually specified dependencies MK_FDEPS=./mk-fdeps # ... .PHONY: depend depend deps.mk: $(MK_FDEPS) $(srcs) > deps.mk # ... -include deps.mk ``` The full makefile can be found in the following hidden box: > **Makefile2 (click here)** > > ```auto > BUILD_DIR ?= build > PREFIX ?= /usr/local/bin > > FC=gfortran > FC_FLAGS=-O0 -g -fbounds-check -J$(BUILD_DIR) > > # Built with manually specified dependencies > MK_FDEPS=./mk-fdeps > > .PHONY: all clean > all: $(BUILD_DIR)/mk-fdeps > > $(BUILD_DIR): > mkdir -p $@ > > $(BUILD_DIR)/%.o: src/%.f90 | $(BUILD_DIR) > $(FC) $(FC_FLAGS) -c $< -o $@ > > srcs = $(wildcard src/*.f90) > target_deps = $(srcs:src/%.f90=$(BUILD_DIR)/%.o) > > $(BUILD_DIR)/mk-fdeps: $(target_deps) | $(BUILD_DIR) > $(FC) $(FC_FLAGS) $^ -o $@ > > .PHONY: depend > depend deps.mk: > $(MK_FDEPS) $(srcs) > deps.mk > > RM = rm -rf > clean: > $(RM) $(BUILD_DIR) deps.mk > > -include deps.mk > > ``` The sequence of commands to test this from the root project directory is: ```txt make all # original makefile cp build/mk-fdeps . # copy executable into current folder make -f Makefile2 clean # get rid of build folder make -f Makefile2 ``` To ease the bootstrapping process one idea would be to create an _ordered build list_ (see [Module dependencies](https://fortran-lang.discourse.group/t/module-dependencies/1194) ). This is supported by the `nagfor =depend -otype=blist` command or the `compile-order.txt` file generated by [FF08Depends](https://www.megms.com.au/ff08depends.htm). Perhaps the build list could be checked into the repository under `compile-order.txt`: ```txt src/string_builder.f90 src/lexer.f90 src/parser.f90 src/string_arena.f90 src/graph.f90 src/hash_table.f90 src/int_darray.f90 src/makefile_deps.f90 src/main.f90 ``` allowing to bootstrap the tool with a one-liner: ```txt gfortran -o mk-fdeps $(cat compile-order.txt) ``` Afterward you can keep using the Makefile with auto-generated dependencies. You must however make sure the `compile-order.txt` is valid when you check-in any changes. Edit: I just realized the generated `dep.mk` fulfills the same role as `compile-order.txt`. So you could just check that file in and make sure it remains valid when files are added/removed. ---
**Author:** ![urbanjost](https://avatars.discourse-cdn.com/v4/letter/u/0ea827/32.png) [@urbanjost](https://fortran-lang.discourse.group/u/urbanjost)\ **Post date:** [January 7, 2026, 11:35am UTC](https://fortran-lang.discourse.group/t/automatic-make-recipes-generation/10570/10 "2026-01-07T11:35:06Z")
The Cray Fortran compiler, invoked using the `ftn` command, is designed to find Fortran `*.mod` files within archive (`*.a`) files. This behavior is a key feature of the HPE Cray Compiling Environment (CCE). ---
**Author:** ![Jcollins](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/jcollins/32/540_2.png) [@Jcollins](https://fortran-lang.discourse.group/u/Jcollins)\ **Post date:** [January 8, 2026, 2:27pm UTC](https://fortran-lang.discourse.group/t/automatic-make-recipes-generation/10570/11 "2026-01-08T14:27:26Z")
I like that this was done in Fortran! BTW fpt is written in Fortran as well. ---
**Author:** ![rwmsu](https://avatars.discourse-cdn.com/v4/letter/r/48db29/32.png) [@rwmsu](https://fortran-lang.discourse.group/u/rwmsu)\ **Post date:** [January 8, 2026, 3:44pm UTC](https://fortran-lang.discourse.group/t/automatic-make-recipes-generation/10570/12 "2026-01-08T15:44:11Z")
I seem to remember that the early versions of CCE did not directly support module files with a .mod extension. Modules were compiled to a .o like other binary objects (no separate .mod file) therefore they would be added to an archive like other .o files. I think there may have been a compiler option to use .mod but its something the user had to add to their compiler statements. Backwards compatability might have been a reason Cray chose to allow .mod files in archives. ---
**Author:** ![mecej4](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/mecej4/32/855_2.png) [@mecej4](https://fortran-lang.discourse.group/u/mecej4)\ **Post date:** [January 8, 2026, 5:14pm UTC](https://fortran-lang.discourse.group/t/automatic-make-recipes-generation/10570/13 "2026-01-08T17:14:45Z")
I built the exe using Intel fortran on Windows. When I ran the exe with “\*.f90” as the argument, the response was: `forrtl: severe (43): file name specification error, unit -129, file S:\MKMF\mk-fdeps-main\src\*.f90 <...stack trace...>` When I ran with all the .f90 names as a sequence of arguments, I was given the contents of the resulting makefile on the console. Perhaps some guidance could be given on how to use the tool on Windows. I also found that I had to change “popen” to “\_popen” and “pclose” to “\_pclose” before building the utility using Intel Fortran. ---
**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:** [January 8, 2026, 5:28pm UTC](https://fortran-lang.discourse.group/t/automatic-make-recipes-generation/10570/14 "2026-01-08T17:28:41Z")
> [@mecej4](#): > > I built the exe using Intel fortran on Windows. When I ran the exe with “\*.f90” as the argument, the response was: > `forrtl: severe (43): file name specification error, unit -129, file S:\MKMF\mk-fdeps-main\src\*.f90 <...stack trace...>` I assume this is because the Windows `cmd.exe` does not expand the `*` wildcard: [https://stackoverflow.com/a/70222438](https://stackoverflow.com/a/70222438) It would then be up to the application to call the Win32 procedures, [FindFirstFileA](https://learn.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-findfirstfilea), [FindNextFileA](https://learn.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-findnextfilea), [FindClose](https://learn.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-findclose). Presumably, Intel Fortran provides interface blocks in the `ifwin` extension module. With gfortran on Windows, it might be easier to run the executable under a Cygwin shell, where the expansion is done by the shell. Here’s a quick program to test the shell expansion behavior: ```auto ! test_args.f90 program test_args character(len=100) :: arg integer :: i do i = 1, command_argument_count() call get_command_argument(i, arg) print *, "Argument ", i, ": ", trim(arg) end do end program test_args ``` ```auto $ gfortran -Wall test_args.f90 $ ./a.out "src/*.f90" Argument 1 : src/*.f90 $ ./a.out src/*.f90 Argument 1 : src/graph.f90 Argument 2 : src/hash_table.f90 Argument 3 : src/int_darray.f90 Argument 4 : src/lexer.f90 Argument 5 : src/main.f90 Argument 6 : src/makefile_deps.f90 Argument 7 : src/parser.f90 Argument 8 : src/string_arena.f90 Argument 9 : src/string_builder.f90 ``` I’m using `bash` on a Mac. ---
**Author:** ![lsmenicucci](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/lsmenicucci/32/4817_2.png) [@lsmenicucci](https://fortran-lang.discourse.group/u/lsmenicucci)\ **Post date:** [January 29, 2026, 8:47pm UTC](https://fortran-lang.discourse.group/t/automatic-make-recipes-generation/10570/15 "2026-01-29T20:47:28Z")
Hi all, is very nice to come back from a vacation and see all these interesting replies. I was definitely NOT familiar with the big family of Makefile generators we have spread in the wild. My initial intention, besides the Makefile problem, was to experiment some data structures in Fortran and prepare the grounds to write a full recursive descent parser for a future LSP. Also, I just updated the tool so it uses a state machine based lexer (generated by [re2c](https://re2c.org)) which is orders of magnitude faster than the original handwritten one. Unfortunately, this adds a C file which, as far as I know, prevents the tool to be packed into a single source file, as suggested by @**[urbanjost](https://fortran-lang.discourse.group/u/urbanjost)**. ---
**Author:** ![lsmenicucci](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/lsmenicucci/32/4817_2.png) [@lsmenicucci](https://fortran-lang.discourse.group/u/lsmenicucci)\ **Post date:** [January 29, 2026, 8:57pm UTC](https://fortran-lang.discourse.group/t/automatic-make-recipes-generation/10570/16 "2026-01-29T20:57:23Z")
That’s a very relevant issue, I’ve abandoned fpm particularly because of the benefits of Make (parallel builds, only build dependent files, predictable performance). I would be happy to contribute. ---
**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:** [April 14, 2026, 11:09pm UTC](https://fortran-lang.discourse.group/t/automatic-make-recipes-generation/10570/17 "2026-04-14T23:09:38Z")
> [@lsmenicucci](#): > > Unfortunately, this adds a C file which, as far as I know, prevents the tool to be packed into a single source file, as suggested by @**[urbanjost](https://fortran-lang.discourse.group/u/urbanjost)**. With _gfortran_ at least, you can also build C files with the same driver, ```txt $ cat hello.c #include // Subroutine definition void print_hello() { printf("Hello, world!\n"); } $ cat hello_from_fortran.f90 interface subroutine print_hello() bind(c) end subroutine end interface call print_hello() end $ gfortran hello.c hello_from_fortran.f90 && ./a.out Hello, world! ``` So you could package the files into a tarball and anyone could built it with a one-liner: ```auto tar -xf mk-fdeps.tar.gz && cd mk-fdeps && \ gfortran -o mk-fdeps lexer.c $(cat compile-order.txt) ``` It’s still very minimalistic. ---
**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:** [April 24, 2026, 6:25pm UTC](https://fortran-lang.discourse.group/t/automatic-make-recipes-generation/10570/18 "2026-04-24T18:25:07Z")
Maybe in the future, flang will provide a robust option for dependency generation: > **[\[RFC\] Flang Dependency Scanning for CMake](https://discourse.llvm.org/t/rfc-flang-dependency-scanning-for-cmake/90620)** > > RFC: Flang — Fortran Dependency Scanning for CMake Summary and Motivation This RFC proposes adding a dependency scanning mode to Flang. When invoked with new -fdeps- flags, Flang will preprocess and parse a Fortran translation unit without...