Who is using fortran-lang projects (fpm, stdlib, minpack, fftpack, vscode-support)?

I have been quite happy using fpm on some large projects. That’s not to say there aren’t large projects for which fpm would not serve them well, and I’m not familiar with the examples you give, but I haven’t encountered a scenario where fpm didn’t make my life much easier.


it would be useful to add an example (a single example), on the Fortran Package Manager — Fortran Package Manager, that includes all cases described in the example_package directory of the fpm repository.

I tend to agree with @everythingfunctional about fpm. I was recently able to build METIS and ParMETIS in C with zero effort. Might not be big projects in terms of lines of code but the ydefinitely have a massive impact when it comes to partitioning software.


Nice. I would be interested to see the fpm toml…

1 Like

The fpm did all of the heavy lifting, the configuration files are pretty normal see METIS fpm.toml and ParMETIS fpm.toml

Both of them are still very work in progress (especially the ParMETIS repo) and I still need to fix a couple bugs in fpm that would make creating such projects a lot easier. This just goes to show that fpm has a lot of untapped potential; resolving compilation order, decentralised dependencies via Git, tree shaking and parallel builds are game changers!

I think that in a lot of cases we would be able to port major scientific codes to fpm with minimal effort.


I believe that for many “large” scientific projects having file-dependent compilation flags (and maybe other similar fine tuning functionality) is crucial, mainly when dealing with the inevitable amount of legacy stuff (that may well not reach the API, but still has to be compiled). As an example see my comment on a related post:

More generally both CMake and cargo (which is the main inspiration for fpm, as I understand) provide easy directory-based differentiation of the build options. The former via the pervasive nested CMakeLists.txt + add_subdirectory pattern, the latter I don’t know well, but I see it’s extensively used in DFTWorks. But for what I got skimming through several disseminated discussions (github issues mostly I think) this is not planned for fpm, so that could be a nontrivial barrier for very large and especially heterogeneous projects…

True, local preprocessor definitions within a package is not currently how things are done in fpm, but given that preprocessor support for fpm was added this summer I wouldn’t make any sweeping statements. Maybe this can be a GSoC project for next year, @lkedward what do you think?

1 Like

Oh sorry, didn’t really mean to communicate that. I thought it was a precise design choice to have just a single, centralized, manifest file. I’m happy if it’s still to be decided :slight_smile:

1 Like

Having more control over compilation flags, including per-file flags, is definitely planned for fpm. We had a GSoC student do a significant amount of good work towards this (see this presentation: https://tcevents.chem.uzh.ch/event/14/contributions/66/attachments/63/142/Hanling_compiler_flags_in_fpm.pdf). Unfortunately the full work hasn’t been merged since some implementation details remain unresolved. It is a really difficult problem to solve, that has no equivalent in other package managers, since we must support multiple compilers across multiple OSes while also respecting different flags for different dependencies and possible interactions between them. I’m very keen to get this finished since I think it’s the last major feature missing from fpm, unfortunately it will require paid time to do IMO.


Some internal programs (the biggest is 79 000, lines of Fortran, 16 000, lines of C) are now built with fpm; and nearly all of my github repositories, in different levels of progress from complete packages
to WIPs and experiments build with fpm -

Miscellaneous Modules

Command-line Arguments






Everything, almost


Amazing @urbanjost, thank you for putting this list together. I stumbled across many of these projects when I was trying to calculate the number of fpm projects. Your list is noticeably easier to navigate than the GitHub API JSON files I got.

1 Like

That was generated by using curl to call the API:
curl ‘https://api.github.com/users/urbanjost/repos?per_page=1000
and then making a throw-away fpm program that processed the JSON and wrote md.
Just extracting and formatting “Description” and "url_html"l and then some hand-editing rearranging some of the links and a little editing for some of the labels (they were grouped by hand). Maybe I should have kept that and dressed it up a bit.


Almost all of my opensource libs are now using FPM. Many of the big ones are listed here (see my GitHub repository list for all of them). I think FPM is a game-changer, just what we have needed for a very long time. I was actually a little skeptical at first that we needed such a thing, but am now 100% convinced. The days of manually downloading F77 code from Netlib and manually stuffing them in your makefile are over.

I have a couple of opensouce projects that show how to put all the libs together to do something nontrivial. The most complicated example is here which has a dependency listing in the toml file of:

fortran-astrodynamics-toolkit = { git = "https://github.com/jacobwilliams/Fortran-Astrodynamics-Toolkit", tag = "0.5" }
NumDiff = { git = "https://github.com/jacobwilliams/NumDiff", tag = "1.7.0" }
ddeabm = { git = "https://github.com/jacobwilliams/ddeabm", tag = "3.0.0" }
json-fortran = { git = "https://github.com/jacobwilliams/json-fortran", tag = "8.2.5" }
bspline-fortran = { git = "https://github.com/jacobwilliams/bspline-fortran", tag = "6.1.0" }
pyplot-fortran = { git = "https://github.com/jacobwilliams/pyplot-fortran", tag = "3.2.0" }
fortran-search-and-sort = { git = "https://github.com/jacobwilliams/fortran-search-and-sort", tag = "1.0.0" }
fortran-csv-module = { git = "https://github.com/jacobwilliams/fortran-csv-module", tag = "1.3.0" }
nlesolver-fortran = { git = "https://github.com/jacobwilliams/nlesolver-fortran", tag = "1.2.0" }
argv-fortran = { git = "https://github.com/jacobwilliams/argv-fortran", tag = "1.0.0" }

So, that’s just my own walled garden, but I do have other projects using stuff from other folks. Haven’t yet used stdlib yet, but hopefully will in the future.


Terrific work @urbanjost!

Some of you put my productivity to shame. Well done. I’ll put my list here for since we’re at it (which you can also find here.


here are Some Insights on Fortran Language and its repositories by me (source : github api),

  • There are currently total 29649 repos using fortran . There has been considerable increase in the number of repos since 2019, ( every year 2-3.5k new repos) as compared to earlier ( 0.5k to 1.5k till 2019)

  • As the FPM is new there is still only ~1.4% adoption in the github repos. ( 406 out of 29649), Which presents a very Large Scale growth opportunity , still it can grow exponentially for years.

  • Reference-LAPACK/lapack remains the most starred, watched and forked repo in fortran.

I have curated a dataset of 2k fortran repos on github ( will share them soon) and trying to curate a dataset of all the fortran repos.

Thanks and Regards,


Thank you @jacobwilliams, @everythingfunctional and @henilp105 for the added info.

BTW @henilp105 I would be a bit cautious with calculating adoption of fpm in Fortran projects. It’s difficult to measure the number of unique repos that use or could use a build system and are/aren’t using fpm. For example there are many repo duplicates (not just forks) of BLAS and LAPACK on GitHub that should be excluded from the stats. Another point for consideration is that fpm can be used to build C and C++ projects, should non-Fortran projects using fpm be excluded from the adoption stat? Just some food for thought.

1 Like

@gnikit , thanks sir for the insights and food for thought, for fpm adoption stats I have checked presence of fpm.toml file in repo (thus mostly it seems that it would have also included the c/c++ repos) it would be great if you can suggest a more robust method for it.

For duplicate repos detection (we can easily detect forks by api) how can we approach this problem, it would be great if you could share your insights on this problem.

One way I thought of was to check
1.file name
2.last updated date
3. sha256 checksum of files

In a nested way using graph ql api.

Thanks and Regards,

1 Like

When I was trying to get similar stats for the NumFOCUS application I ended up abandoning the idea of adoption %, it was too hard to estimate and I feared what I had was misleading. I thought a more interesting statistic is how many of the popular computational libraries can fpm build without having to modify the repo or modifying the repo in a standardised way e.g. copy all source files into the ./src directory. I suspect that project list would have to be manually compiled (I had no time for this so I simply skipped it altogether). This would also be a good strategy for finding and implementing new features for fpm.


@gnikit Thanks for the idea and method, will try to make a script with docker to test if that can be done , ( for project list I will try to take most starred , watched and forked repos) .

1 Like