# Fpm 0.12.0 released 🎉 **URL:** \ **Category:** Announcements\ **Created:** [May 18, 2025, 6:05am UTC](https://fortran-lang.discourse.group/t/fpm-0-12-0-released/9745 "2025-05-18T06:05:20Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![FedericoPerini](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/federicoperini/32/1750_2.png) [@FedericoPerini](https://fortran-lang.discourse.group/u/FedericoPerini)\ **Post date:** [May 18, 2025, 6:05am UTC](https://fortran-lang.discourse.group/t/fpm-0-12-0-released/9745/1 "2025-05-18T06:05:20Z")
Dear Fortran enthusiasts, we are excited to announce the release of **fpm v0.12.0**! 🚀 This release brings a set of **major new features** focused on interoperability, modern tooling support, and modular build customization — alongside various fixes and improvements across platforms and compilers. 🔧 **Export `compile_commands.json`** for IDE integration A `compile_commands.json` file is now exported by default every time building with `fpm`, enabling editor features like: - **clangd** support - **VS Code** auto-completion and symbol navigation - Integration with **CMake Tools** , **Language Servers** , and more This brings fpm in line with modern C/C++ workflows and improves IDE integration. 📦 **New BLAS/LAPACK and NetCDF metapackages** Two new [metapackages](https://fpm.fortran-lang.org/spec/metapackages.html) make it easier to link with high-performance scientific libraries: - **BLAS/LAPACK** : Automatically link to system-provided libraries or optimized builds, also when using `stdlib`. - **NetCDF** : Use `pkg-config` to locate NetCDF C and Fortran modules, with broad compiler support. 🧩 **Support for shared and static library targets** Library targets can now specify: ```toml [library] type = "static" type = "shared" type = "monolithic" # default ``` With the `shared` and `static` options, one complete library per dependency package is built and installed. This allows for plugin-style builds, dynamic linking, further than just bundling all required objects into a monolithic archive. ### 🛠 Additional improvements - Windows bootstrapping fixes and Flang OpenMP support - Optional user-defined compiler/linker flags for introspection - Support for custom `--config` files - Enhanced metapackage support for Intel MPI and SLURM `srun` - Ongoing internal refactoring for improved maintainability ### 📥 Download You can grab the latest version from our GitHub releases: 🔗 [GitHub Release Page](https://github.com/fortran-lang/fpm/releases/tag/v0.12.0) ### 👋 New Contributor Please welcome [@krystophny](https://github.com/krystophny), who contributed significant refactoring work and the new NetCDF and BLAS metapackages! ### 💬 Feedback & Discussion Thanks to everyone who contributed to this release! 🙌 We eagerly await to hear your feedback, experiences, and questions on the new experimental features. ---
**Author:** ![fxm](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/fxm/32/5726_2.png) [@fxm](https://fortran-lang.discourse.group/u/fxm)\ **Post date:** [May 18, 2025, 9:08am UTC](https://fortran-lang.discourse.group/t/fpm-0-12-0-released/9745/2 "2025-05-18T09:08:20Z")
Thanks @FedericoPerini, @krystophny and all contributors. That’s a lot of exciting news in one update. > **🧩 Support for shared and static library targets** Yes! 🚀 ---
**Author:** ![vmagnin](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/vmagnin/32/28_2.png) [@vmagnin](https://fortran-lang.discourse.group/u/vmagnin)\ **Post date:** [May 18, 2025, 10:17am UTC](https://fortran-lang.discourse.group/t/fpm-0-12-0-released/9745/3 "2025-05-18T10:17:32Z")
Thanks to @FedericoPerini, @krystophny and all contributors! I have already updated my fpm on one Ubuntu PC. I have seen that [fpm doc](https://fpm.fortran-lang.org/) has been augmented, and I would like to work on updating the French translation. However, on [https://hosted.weblate.org/projects/fortran-lang/fpm/](https://hosted.weblate.org/projects/fortran-lang/fpm/) the French translation is considered to be 100% complete, which is not true. Can someone please synchronize fpm doc & Weblate? ---
**Author:** ![hkvzjal](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/hkvzjal/32/3055_2.png) [@hkvzjal](https://fortran-lang.discourse.group/u/hkvzjal)\ **Post date:** [May 18, 2025, 11:03am UTC](https://fortran-lang.discourse.group/t/fpm-0-12-0-released/9745/4 "2025-05-18T11:03:31Z")
> [@FedericoPerini](#): > > 🧩 **Support for shared and static library targets** This is incredibly amazing!!! I just upgraded fpm in my personal computer to test this: ![image](https://global.discourse-cdn.com/free1/uploads/fortran_lang/original/2X/c/c25439de86d3c8db116af35f37f1fc80e1e4a2c3.png) This will enable easier setups for building Python extensions from Fortran and much more. 🚀 I have to test this with a larger project at work 🙂 There is just one question remaining, is there a way to avoid the labeled archive that changes with every build? I would prefer to have a fixed folder within the build directory to archive the libraries. For instance, with CMake I would typically have a `Release`, `Debug`, `RelWithDebInfo` folders under the build directory. I find this extremely convenient as I systematically know where to point to during development/debugging. ---
**Author:** ![urbanjost](https://avatars.discourse-cdn.com/v4/letter/u/0ea827/32.png) [@urbanjost](https://fortran-lang.discourse.group/u/urbanjost)\ **Post date:** [May 18, 2025, 12:45pm UTC](https://fortran-lang.discourse.group/t/fpm-0-12-0-released/9745/5 "2025-05-18T12:45:59Z")
Nice! There is a small errata in the help text where a line goes over the eighty-column limit. > **errata** > > ```diff > diff --git a/src/fpm_command_line.f90 b/src/fpm_command_line.f90 > index ffb5a5b61..d87741bf7 100644 > --- a/src/fpm_command_line.f90 > +++ b/src/fpm_command_line.f90 > @@ -996,7 +996,8 @@ contains > ' [--tests] [--no-prune] [--config-file PATH] [--dump [FILENAME]] ', & > ' new NAME [[--lib|--src] [--app] [--test] [--example]]| ', & > ' [--full|--bare][--backfill] ', & > - ' update [NAME(s)] [--fetch-only] [--clean] [--config-file PATH] [--dump [FILENAME]]', & > + ' update [NAME(s)] [--fetch-only] [--clean] [--config-file PATH] ', & > + ' [--dump [FILENAME]] ', & > ' run [[--target] NAME(s)] [--profile PROF] [--flag FFLAGS] [--list] [--all] ', & > ' [--example] [--runner "CMD"] [--compiler COMPILER_NAME] ', & > ' [--no-prune] [-- ARGS] [--config-file PATH] ', & > > ``` ---
**Author:** ![urbanjost](https://avatars.discourse-cdn.com/v4/letter/u/0ea827/32.png) [@urbanjost](https://fortran-lang.discourse.group/u/urbanjost)\ **Post date:** [May 18, 2025, 1:19pm UTC](https://fortran-lang.discourse.group/t/fpm-0-12-0-released/9745/6 "2025-05-18T13:19:17Z")
The labeling allows for concurrent builds with different compiler options. Perhaps giving constant names to the default builds might partially solve the problem, so if you supplied no options the names would match the profile names (ie. “debug” and “release”) for those cases; but you can query the pathnames with --list or via the JSON or API. The names in the build directory are assumed to not be needed to be known by the user in the majority of cases, and can be extracted into known pathnames via the “install” subcommand or in some cases via the --runner option. When do you need to point to the files directly? to invoke a debugger? In most cases something like ```auto fpm test --runner gdb ``` might work for that case. An example plugin that does that for simple cases with gdb and vim is [GitHub - urbanjost/fpm-gdb: plugin for fpm(1) that runs gdb(1) in vim(1) on Linux](https://github.com/urbanjost/fpm-gdb). But I am not quite sure if I understand your use-case. ---
**Author:** ![hkvzjal](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/hkvzjal/32/3055_2.png) [@hkvzjal](https://fortran-lang.discourse.group/u/hkvzjal)\ **Post date:** [May 18, 2025, 1:29pm UTC](https://fortran-lang.discourse.group/t/fpm-0-12-0-released/9745/7 "2025-05-18T13:29:44Z")
My use case is: - I do not use `fpm` for myself, and it is not (so far) my main build system. (I’m preparing things to have it ready next to CMake) - I do not build libraries for my own use (only) but to be given. The libraries are part of a bigger solution for which another tool (Artifactory from Jenkins) is used to put everything together (executables, static libraries, shared libraries, documentation, resources, etc etc) So, I would like to have a predefined librarian to know from where to extract the binaries. If I could set a local folder that would be already enough. I have never found any utility in the labeling for concurrent builds honestly, but I won’t argue about that, I’m most likely not seeing something. The CMake convention > [@hkvzjal](#): > > CMake I would typically have a `Release`, `Debug`, `RelWithDebInfo` Is more than enough and I haven’t had the need for more than that. Typically, if I change some flags it is because I’m testing options to decide which will be the optimal release. ---
**Author:** ![FedericoPerini](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/federicoperini/32/1750_2.png) [@FedericoPerini](https://fortran-lang.discourse.group/u/FedericoPerini)\ **Post date:** [May 18, 2025, 1:37pm UTC](https://fortran-lang.discourse.group/t/fpm-0-12-0-released/9745/8 "2025-05-18T13:37:33Z")
Thanks a lot @urbanjost - [errata: CLI help line too long by perazz · Pull Request #1144 · fortran-lang/fpm · GitHub](https://github.com/fortran-lang/fpm/pull/1144) > [@urbanjost](#): > > The labeling allows for concurrent builds with different compiler options exactly, this was defined at [Enable multiple build output directories by awvwgk · Pull Request #575 · fortran-lang/fpm · GitHub](https://github.com/fortran-lang/fpm/pull/575). What’s hashed is the set of build flags so essentially different folders characterize different languages (Fortran/C/C++) AND profiles including sets of CLI flags. > [@hkvzjal](#): > > If I could set a local folder that would be already enough. Of course one can always then `install` everything in a user-defined folder, I doubt that would be time consuming (that’s what I do when developing `fpm` btw). I’m interested to discuss opinions and ideas as I’m planning to start looking at `optional` dependencies and different `profiles`, they would certainly affect this (for example: if a user-defined `profile` (that defines a set of build flags has a `build-dir` or a `name`, then its build folder could be taken from that ---
**Author:** ![hkvzjal](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/hkvzjal/32/3055_2.png) [@hkvzjal](https://fortran-lang.discourse.group/u/hkvzjal)\ **Post date:** [May 18, 2025, 1:45pm UTC](https://fortran-lang.discourse.group/t/fpm-0-12-0-released/9745/9 "2025-05-18T13:45:40Z")
This would be great! A `build-dir` like option could solve it! I understood that when `install`ing, it copies libraries to a predefined folder in the system. What I’m looking for is more of a local archiving (within the project’s `build` directory) ---
**Author:** ![FedericoPerini](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/federicoperini/32/1750_2.png) [@FedericoPerini](https://fortran-lang.discourse.group/u/FedericoPerini)\ **Post date:** [May 18, 2025, 1:52pm UTC](https://fortran-lang.discourse.group/t/fpm-0-12-0-released/9745/10 "2025-05-18T13:52:26Z")
```auto fpm install --prefix=build/Release ``` should do exactly what you’re asking (there will be `build/Release/lib` `build/Release/include` and `build/release/bin`) ---
**Author:** ![urbanjost](https://avatars.discourse-cdn.com/v4/letter/u/0ea827/32.png) [@urbanjost](https://fortran-lang.discourse.group/u/urbanjost)\ **Post date:** [May 18, 2025, 2:01pm UTC](https://fortran-lang.discourse.group/t/fpm-0-12-0-released/9745/11 "2025-05-18T14:01:46Z")
```bash fpm install --no-rebuild --prefix build/debug ``` might be what you are looking for, but I would in general not recommend placing files in build/, as it is often something you want to clean up (ie. remove) and it would remove the directory. ```auto fpm install --no-build --prefix=releases/v1.0.0 ``` or something like that (which would put everything in the directory releases/v1.0.0/ in the project area) might be better, and let you also delete and rebuild the “releases” as well. So an inadvertent “clean” might remove the files. Also, the build/ directory is excluded from inclusion into git by default, whereas a new directory just for releases can be recorded by git. The feature to note is you can specify with --prefix where the install is directed. ---
**Author:** ![urbanjost](https://avatars.discourse-cdn.com/v4/letter/u/0ea827/32.png) [@urbanjost](https://fortran-lang.discourse.group/u/urbanjost)\ **Post date:** [May 18, 2025, 2:04pm UTC](https://fortran-lang.discourse.group/t/fpm-0-12-0-released/9745/12 "2025-05-18T14:04:55Z")
I was a bit too slow and see this approach was already suggested, but the key is you can install wherever you like with --prefix. From you description you also probably want to change the default install options in your fpm.toml file so “library=true”. Per the manual ```plaintext **strong text** [install] # Options for the "install" subcommand # When you run the "install" subcommand only executables are installed by # default on the local system. Library projects that will be used outside of # "fpm" can set the "library" boolean to also allow installing the module # files and library archive. Without this being set to "true" an "install" # subcommand ignores parameters that specify library installation. # If your project sets `[library] type = "shared"`, enabling this option # will install the compiled `.so`, `.dylib`, or `.dll` files into the # appropriate `lib/` folder. This applies equally to static archives. # # For shared libraries, installing is typically required for runtime usage. library = false ``` ---
**Author:** ![hkvzjal](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/hkvzjal/32/3055_2.png) [@hkvzjal](https://fortran-lang.discourse.group/u/hkvzjal)\ **Post date:** [May 18, 2025, 2:14pm UTC](https://fortran-lang.discourse.group/t/fpm-0-12-0-released/9745/13 "2025-05-18T14:14:46Z")
Thank you both @FedericoPerini @urbanjost, I’ll try to use your recommendations next week to polish my current use of fpm! ---
**Author:** ![urbanjost](https://avatars.discourse-cdn.com/v4/letter/u/0ea827/32.png) [@urbanjost](https://fortran-lang.discourse.group/u/urbanjost)\ **Post date:** [May 18, 2025, 2:41pm UTC](https://fortran-lang.discourse.group/t/fpm-0-12-0-released/9745/14 "2025-05-18T14:41:03Z")
An early branch of fpm(1) allowed you to give a name to your options and to supply compiler options only on the build command. You then used that name on the other commands. The consensus at the time was that the options should become user-defined options in the fpm-toml so that it would become part of the package and be able to be used when the package was a dependency, so that option was removed and --profile was added. But since then many compiler and load options have been made available via switches and environment variables and response files. There was a project and pull request to implement the original vision that I thought was practically finished (a GSOC project (?)) that seems to never have made it into production that dealt with applying switches to specific compilers, conditionally selecting options based on the OS, applying options only to particular files, and so on. But experience has shown there are options for development (debugging, but also for profiling, coverage tools, and other metrics) that might not be needed as part of the distribution; that conditional selection by name might suffice but that something like if-else-endif selection that is aware of the compiler and OS might be nice, and that being able to put the options in a file that can be shared between projects would be nice for the developer but might make it harder to ensure the options are included in the package distribution. Not sure what the flaw was in the previous mods to create user-defined profiles but even if fpm has diverged too much to salvage any of that directly there are at least some ideas and lessons to be taken from that project I would guess. So 1. What users are not using fpm because of a lack of customizable package profiles? 2. How is this feature implemented in other packages? I think a separate toml file called profile.toml that is able to be rewritten by utilities that contains any profiles needed by the package when used as a dependency would be nice. You could have others searched for or in a config file but entries can be updated by adding a flag like --new-profile NAME to a build subcommand. That would take the environment variables and switches used on the build command and build a profile and put it into the profile.toml file. A new fpm-profile plug-in would let you list, remove, and add to the file. At a minimum you can specify a default for a compiler and OS combination so someone using the package as a dependency gets the right switches used. One difficulty is deciding if dependencies that call dependencies get options passed on and is so how? So if on my build command I add a compiler flag does it get passed on to the build like a current dependency so I can optimize, profile, or debug all the code my application is using? Or can I specify that a dependency (and perhaps its dependencies) must use a certain set of options when used as a dependency? ---
**Author:** ![jacobwilliams](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/jacobwilliams/32/10_2.png) [@jacobwilliams](https://fortran-lang.discourse.group/u/jacobwilliams)\ **Post date:** [May 18, 2025, 2:41pm UTC](https://fortran-lang.discourse.group/t/fpm-0-12-0-released/9745/15 "2025-05-18T14:41:20Z")
First of all: shared library support is amazing! Thanks!!! However, I think there is a little wrinkle that would need to be ironed out. This example is for a Mac. Say I’m using `type = "shared"` for a program that has various dependencies: ```auto ./fpm install --profile release --prefix ./install ``` So far so good, it looks like it built all the `.dylib`’s and put them in `./install/lib`. However, if we use `otool` like so on the main program: ```auto > otool -L ./install/bin/coefficients ./install/bin/coefficients: build/gfortran_9CDE8BC29ABA481B/libroots-fortran.dylib (compatibility version 0.0.0, current version 0.0.0) build/gfortran_9CDE8BC29ABA481B/libpyplot-fortran.dylib (compatibility version 0.0.0, current version 0.0.0) build/gfortran_9CDE8BC29ABA481B/libFACE.dylib (compatibility version 0.0.0, current version 0.0.0) build/gfortran_9CDE8BC29ABA481B/libmpfun2020-var1.dylib (compatibility version 0.0.0, current version 0.0.0) build/gfortran_9CDE8BC29ABA481B/librklib.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libgfortran.5.dylib (compatibility version 6.0.0, current version 6.0.0) @rpath/libquadmath.0.dylib (compatibility version 1.0.0, current version 1.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1351.0.0) ``` we notice that the paths to the original locations where they were built are embedded in the application. So, when the `build` folder is deleted, the program will no longer work. So, I think we have to do something here… I admit I’ve never fully understood the `rpath` thing, maybe someone here knows the solution for that? I think you have to patch the binary to change the path using something like `patchelf`, which is, I believe, what `conda` does when you have shared libs in conda packages. EDIT: I guess, on the Mac you would use `install_name_tool` to do something like this: ```auto install_name_tool -change build/gfortran_9CDE8BC29ABA481B/libpyplot-fortran.dylib @rpath/libpyplot-fortran.dylib ./coefficients ``` ---
**Author:** ![FedericoPerini](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/federicoperini/32/1750_2.png) [@FedericoPerini](https://fortran-lang.discourse.group/u/FedericoPerini)\ **Post date:** [May 18, 2025, 4:37pm UTC](https://fortran-lang.discourse.group/t/fpm-0-12-0-released/9745/16 "2025-05-18T16:37:34Z")
Thanks! I’m really glad you’re trying out the new `shared` support. You are totally right: the `.dylib` paths are hardcoded to the build directory because we haven’t yet implemented proper `@rpath` rewriting in the installation step. For this initial version, my main goal was to ensure that: - all dependencies are linked correctly in topological order, - the build succeeds and produces valid `.dylib`s, - and that `fpm run` and `fpm test` work by temporarily adjusting `LD_LIBRARY_PATH` (or `PATH` on Windows). I intentionally left out `install_name_tool` logic for this release, hoping to discuss with the community on what the best default behavior should be, since it can vary between packaging use cases (e.g., relocatable installations vs. system-wide installs vs. development workflows). At work, we explicitly set the install name of each `.dylib` to use `@rpath`: ```bash -Wl,-install_name,@rpath/$(TARGET_OUTPUT_FILENAME) ``` Then, for each executable, we ensure it can locate those by adding an rpath at runtime: ```bash install_name_tool -add_rpath @executable_path ./my_program ``` This tells the dynamic loader to look for libraries in the same directory as the binary itself. It’s a portable pattern that works well for self-contained app bundles or local installs. Going forward, I’d like to explore having fpm: 1. assume all shared libraries are in a common location (e.g., `prefix/lib`) 2. rewrite the install names using `@rpath` 3. inject `@executable_path/../lib` as a default `rpath` in installed binaries But I’m also open to more flexible options, any thoughts or suggestions on the best default behavior (or optional behaviors) are very welcome! ---
**Author:** ![FedericoPerini](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/federicoperini/32/1750_2.png) [@FedericoPerini](https://fortran-lang.discourse.group/u/FedericoPerini)\ **Post date:** [May 18, 2025, 4:43pm UTC](https://fortran-lang.discourse.group/t/fpm-0-12-0-released/9745/17 "2025-05-18T16:43:57Z")
Thanks - I’m aware of that prototype, and I think it would be a good place to build upon. I see a _profile_ as analogous to what Cargo offers: a named configuration that can control compiler flags, feature toggles, and even optional dependencies - basically a whole `fpm.toml` all encoded as a sub-tree of the manifest. This makes the configuration reproducible, distributable, and dependency-aware. Supporting user-defined profiles at this level would let us separate development options (like coverage, profiling, or debug builds) from production ones, while still enabling local overrides or tools to generate new profiles (`--new-profile`, as you suggested). So yeah it’s definitely worth revisiting and iterating upon in light of the more complex use cases and the maturity of fpm’s infrastructure. ---
**Author:** ![Carltoffel](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/carltoffel/32/1680_2.png) [@Carltoffel](https://fortran-lang.discourse.group/u/Carltoffel)\ **Post date:** [May 19, 2025, 8:04am UTC](https://fortran-lang.discourse.group/t/fpm-0-12-0-released/9745/18 "2025-05-19T08:04:19Z")
I’m considering to help with the development of fpm for quite some time, but I lost track of all the new features. What’s the status of the documentation? If it’s up-to-date, I would first read through it. If not, I would start improving the documentation. Or is there anything else where I could start? ---
**Author:** ![icpup](https://avatars.discourse-cdn.com/v4/letter/i/e79b87/32.png) [@icpup](https://fortran-lang.discourse.group/u/icpup)\ **Post date:** [May 21, 2025, 6:44pm UTC](https://fortran-lang.discourse.group/t/fpm-0-12-0-released/9745/19 "2025-05-21T18:44:58Z")
fpm 0.12 failed with gfortran 15.1.1 with a segment fault error, at mean time fpm 0.11 works with gfortran 15.1.1 ---
**Author:** ![FedericoPerini](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/federicoperini/32/1750_2.png) [@FedericoPerini](https://fortran-lang.discourse.group/u/FedericoPerini)\ **Post date:** [May 21, 2025, 9:00pm UTC](https://fortran-lang.discourse.group/t/fpm-0-12-0-released/9745/20 "2025-05-21T21:00:07Z")
Likely due to this gcc15 bug: > [@Error building csv-fortran with fpm](https://fortran-lang.discourse.group/t/error-building-csv-fortran-with-fpm/9760/4): > > I believe you’re right: just had a chance to test it with an updated MSYS2 environment, and indeed, it crashes. I found that fpm was built on MSYS with gcc-15 which we do not support yet and apparently it crashes (likely compiler bug, ugh) at this default initializer: ! Fill in the compile\_command\_t cmd = compile\_command\_t(directory = string\_t(cwd), & arguments = [(string\_t(trim(args(i))), i=1,n)], & file = string\_t… Note gcc-15 is not among the fpm-supported compilers (at least yet) [Next page](https://fortran-lang.discourse.group/t/fpm-0-12-0-released/9745.md?page=2)