# 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:** 1\ **Showing post:** 5
**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? --- _[View the full topic](https://fortran-lang.discourse.group/t/automatic-make-recipes-generation/10570)._