I’m using fpm to develop neural-fortran and for experimenting. I also use the VS Code Modern Fortran extension.
Consider making a multi-choice poll on this as it may reduce the friction to respond.
I’m using fpm to develop neural-fortran and for experimenting. I also use the VS Code Modern Fortran extension.
Consider making a multi-choice poll on this as it may reduce the friction to respond.
If fpm had existed at the start of my PhD, I would have made significant use of it. I use it now for spinning up little test projects and testing existing packages. There are few old projects I want to convert to fpm, but I’ve not found the time unfortunately.
I use the sorting module from stdlib now and again. I know a lot of good work went into it and it’s well-tested etc. (Also stdlib as a fpm dependency is much more manageable now that fpm has tree-shaking.)
I also use Modern Fortran VSCode (but I need to fix the linting support!)
To support the NumFOCUS application, it might be worth pointing out the large number of available projects that already support fpm. I don’t have an up-to-date list but at last FortranCon I think it was 170+. I think Sebastian @awvwgk has a way of enumerating the ones on Github.
Try searching on GitHub with
https://github.com/search?o=desc&q=path%3A%2F+filename%3Afpm.toml&s=indexed&type=Code
Created a poll from the list
In my daily research, fpm has been great for getting small projects up and running with minimal hassle. It makes Fortran a much more appealing language for prototyping. I’m also using stdlib more and more, mainly the kinds, sorting, error checking, and quadrature modules.
I haven’t used any of the packs yet, but a code I wrote in grad school depends on fftpack. When the time comes to dust it off, I will definitely add fpm integration to automatically build the fortran-lang fftpack.
I voted for fpm
and the VScode extension cause I use them a lot more and intend to continue / expand on it too:
the extension is installed an running on all my laptops + on the office workstation, it is very convenient, thanks a lot!
fpm
to me represent a revolution on how fortran development feels; now I want to do it, now I’m happy to start prototyping stuff directly in it, now I’m starting to seriously considering ditching Matlab (though I might wait just a little bit more for the LFortran revolution ). Actually it had sparkled quite a bit of Rust hype in me, exactly for the evident similarity with the
cargo
workflow, at some point I would try coding something in that language (probably nothing serious, it is far out of my comfort zone and not too much convenient for my usual needs).
Nevertheless I’ve also recently included the stdlib in a recent new project, with a bit of caveats and pain-points that I’ve extensively described in a dedicated post therein.
I just gave a lecture about a Python wrapper for a well-known gradient-based optimization library in the geophysical field (GitHub - ofmla/seiscope_opt_toolbox_w_ctypes: This repo shows how to use SEISCOPE optimization toolbox Fortran code from Python), which is written in Fortran. I made some modification to the original Fortran code to make the wrapper work and showed how to build the library using fpm for those who are only interested in the Fortran library. I hope to have draw attention of the students to fpm potential. BTW, the fpm logo is really nice.
My impression is that fpm only works with small projects. Not sure if fpm can work with larger projects like flexi and UCNS3D:
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.
Maybe,
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…
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?
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
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 -