# Fpm version 0.8.0 released **URL:** \ **Category:** Announcements\ **Created:** [April 7, 2023, 11:07am UTC](https://fortran-lang.discourse.group/t/fpm-version-0-8-0-released/5520 "2023-04-07T11:07:51Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![awvwgk](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/awvwgk/32/154_2.png) [@awvwgk](https://fortran-lang.discourse.group/u/awvwgk)\ **Post date:** [April 7, 2023, 11:07am UTC](https://fortran-lang.discourse.group/t/fpm-version-0-8-0-released/5520/1 "2023-04-07T11:07:51Z")
We just released fpm version 0.8.0, many thanks to everyone who contributed patches. This release introduces support for enabling and disabling language features in fpm, such as implicit typing or default source form. By default, fpm now tries to disable implicit typing rules, implicit external interfaces and assumes the source form is always free. The options can be overwritten in the manifest for each project. Furthermore, first support for local and remote registries are integrated in fpm. The registry support can be configured in a new global configuration file. This development was sponsored by the [Sovereign Tech Fund](https://sovereigntechfund.de/en/projects/fortran/). Bugfixes and improvements to the preprocessor support, C++ compilation, dependency updates and more are included in this release. Find the full release notes [here](https://fpm.fortran-lang.org/en/news/2023/04-07-fpm-version-0.8.0.html) or on [GitHub](https://github.com/fortran-lang/fpm/releases/tag/v0.8.0). ---
**Author:** ![gnikit](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/gnikit/32/1213_2.png) [@gnikit](https://fortran-lang.discourse.group/u/gnikit)\ **Post date:** [April 7, 2023, 12:07pm UTC](https://fortran-lang.discourse.group/t/fpm-version-0-8-0-released/5520/2 "2023-04-07T12:07:47Z")
Amazing work to everyone involved! Very glad to see the registry work reach end users. ---
**Author:** ![awvwgk](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/awvwgk/32/154_2.png) [@awvwgk](https://fortran-lang.discourse.group/u/awvwgk)\ **Post date:** [April 7, 2023, 2:23pm UTC](https://fortran-lang.discourse.group/t/fpm-version-0-8-0-released/5520/3 "2023-04-07T14:23:30Z")
Big shout-out to Minh @minhdao, Federico @FedericoPerini, Henil @henilp105, and Arteev @arteevraina for their amazing work on fpm and the registry server! Looking forward to see the first public demo of the registry launching soon. ---
**Author:** ![urbanjost](https://avatars.discourse-cdn.com/v4/letter/u/0ea827/32.png) [@urbanjost](https://fortran-lang.discourse.group/u/urbanjost)\ **Post date:** [April 7, 2023, 2:56pm UTC](https://fortran-lang.discourse.group/t/fpm-version-0-8-0-released/5520/4 "2023-04-07T14:56:58Z")
Adding new keywords to the manifest is a significant issue, as it currently means any package you release cannot be built with a previous version of fpm. So for instance, if you add “module-naming” to your fpm.toml file build directives the package cannot be used as a dependency by anyone using a pre-0.8.0 fpm version. ```plaintext $ fpm7 build *cmd_build*:package error:Key module-naming is not allowed in [build] STOP 1 ``` - should fpm be changed so unrecognized names produce a warning instead of an error (if possible)? - should a preprocessor be supported for fpm.toml files that allows simple cpp-like preprocessing so you could have something like - should multiple fpm.toml files be supported with a rule for naming them that lets fpm choose one appropriately? Perhaps fpm\_0.7.0.toml would indicate if you are using fpm 0.7.0 to use that by default? It could be useful to have a --manifest FILENAME switch for other reasons like specifying different executables or libraries or compiler options but that gets more complicated with remote dependencies if anything manual becomes required. There have been discussions about allowing for fpm.toml files to require a specific version or perhaps a version expression such as a range, but perhaps something more general should be considered? Otherwise, new features like this will be slow to be adapted as they would break usage by anyone without the latest fpm(1) version, although so far updating fpm versions is relatively simple (and could even been automated in some cases). ---
**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:** [April 7, 2023, 3:46pm UTC](https://fortran-lang.discourse.group/t/fpm-version-0-8-0-released/5520/5 "2023-04-07T15:46:41Z")
Thank you @urbanjost, these are all very good points that we’ve also started discussing about. What I’m confident I can say so far is: > [@urbanjost](#): > > - should fpm be changed so unrecognized names produce a warning instead > of an error (if possible)? I also support this idea but we did not discuss a viable future strategy yet. I think we should consider fpm still “alpha” software, whose user interface (including the manifest) is still subject to change. We try to minimize that, but it’s impossible to introduce quite a lot new features while at the same time avoiding any changes to the input tables. > [@urbanjost](#): > > - should a preprocessor be supported We are in the process of discussing version constraints, and I’d say the most likely candidate is that we’ll have the option to request a minimum version of fpm in the manifest, something like: ```toml [dependencies] fpm = ">=0.8.0" ``` Something like this will not be as flexible as you’re suggesting, but it would mitigate versioning and backward compatibility issues. > [@urbanjost](#): > > - It could be useful to have a --manifest FILENAME To me, this looks like a very good idea, let’s see what the community thinks. ---
**Author:** ![alirezagh76](https://avatars.discourse-cdn.com/v4/letter/a/838e76/32.png) [@alirezagh76](https://fortran-lang.discourse.group/u/alirezagh76)\ **Post date:** [April 7, 2023, 4:14pm UTC](https://fortran-lang.discourse.group/t/fpm-version-0-8-0-released/5520/6 "2023-04-07T16:14:12Z")
It seems that the default behavior setting in fpm-0.8 has changed, for example, it is using the compiler option “-free” when using ifort. This may not be suitable as a default for old \*.f files. ---
**Author:** ![urbanjost](https://avatars.discourse-cdn.com/v4/letter/u/0ea827/32.png) [@urbanjost](https://fortran-lang.discourse.group/u/urbanjost)\ **Post date:** [April 7, 2023, 5:41pm UTC](https://fortran-lang.discourse.group/t/fpm-version-0-8-0-released/5520/7 "2023-04-07T17:41:48Z")
I have not traced down the cause yet; but doing a rebuild of a lot of projects with version 0.8.0 I am seeing remote dependencies being pulled down from the WWW every time there is a build. Anyone else seeing something similar? ---
**Author:** ![awvwgk](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/awvwgk/32/154_2.png) [@awvwgk](https://fortran-lang.discourse.group/u/awvwgk)\ **Post date:** [April 7, 2023, 7:28pm UTC](https://fortran-lang.discourse.group/t/fpm-version-0-8-0-released/5520/8 "2023-04-07T19:28:14Z")
Yes, we have taken a controversial route there, disabling some language features by default, like implicit typing or fixed form. Going forward those will be opt-in features on per project basis, to revert to the previous behavior add the following lines to the manifest ```ini [fortran] implicit-typing = true implicit-external = true source-form = "default" ``` We think that this way we can make it easier for newcomers to start with Fortran via fpm while still allowing established projects to make a choice on the respective features. ---
**Author:** ![FortranFan](https://avatars.discourse-cdn.com/v4/letter/f/96bed5/32.png) [@FortranFan](https://fortran-lang.discourse.group/u/FortranFan)\ **Post date:** [April 7, 2023, 7:37pm UTC](https://fortran-lang.discourse.group/t/fpm-version-0-8-0-released/5520/9 "2023-04-07T19:37:01Z")
> [@awvwgk](#): > > Yes, we have taken a controversial route there … Thank you for the changes in this release of `fpm`, you can rest assured they are better for the users particularly because it is only the defaults that have changed and you’ve put in the hard work that allows the users to override the changes. ---
**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:** [April 7, 2023, 9:24pm UTC](https://fortran-lang.discourse.group/t/fpm-version-0-8-0-released/5520/10 "2023-04-07T21:24:42Z")
> [@FedericoPerini](#): > > > [@urbanjost](#): > > > > - should fpm be changed so unrecognized names produce a warning instead > > of an error (if possible)? > > I also support this idea but we did not discuss a viable future strategy yet. We discussed this point somewhere and I strongly recommend not to do this, otherwise users will just learn to ignore these warnings. Instead, let’s give an error and allow to require a certain fpm version, much like cmake does it. Then projects can decide if they will use a given feature (and require a newer fpm), or not and allow older fpm as well. ---
**Author:** ![RonShepard](https://avatars.discourse-cdn.com/v4/letter/r/a3d4f5/32.png) [@RonShepard](https://fortran-lang.discourse.group/u/RonShepard)\ **Post date:** [April 7, 2023, 9:53pm UTC](https://fortran-lang.discourse.group/t/fpm-version-0-8-0-released/5520/11 "2023-04-07T21:53:48Z")
> [@awvwgk](#): > > Yes, we have taken a controversial route there, disabling some language features by default, like implicit typing or fixed form. Ironically, in another thread the intel compiler is being criticized because it also requires compiler options in order to invoke standard compliance. I guess it is just human nature, but why is it so difficult for one person to learn from another’s previous mistake? ---
**Author:** ![FortranFan](https://avatars.discourse-cdn.com/v4/letter/f/96bed5/32.png) [@FortranFan](https://fortran-lang.discourse.group/u/FortranFan)\ **Post date:** [April 7, 2023, 10:10pm UTC](https://fortran-lang.discourse.group/t/fpm-version-0-8-0-released/5520/12 "2023-04-07T22:10:35Z")
> [@RonShepard](#): > > but why is it so difficult for one person to learn from another’s previous mistake? The separate discussion in the other thread re: -standard-semantics default with Intel looks forward and the fpm.changes here too look forward. So they are all learning to move forward from others’ mistakes, especially by those who insist on latching on to legacy for way too long. ---
**Author:** ![urbanjost](https://avatars.discourse-cdn.com/v4/letter/u/0ea827/32.png) [@urbanjost](https://fortran-lang.discourse.group/u/urbanjost)\ **Post date:** [April 7, 2023, 10:19pm UTC](https://fortran-lang.discourse.group/t/fpm-version-0-8-0-released/5520/13 "2023-04-07T22:19:29Z")
The biggest issue is the use of remote dependencies. Cmake is primarily just a build system and not one a lot of people rave about. If you create a situation where dependencies require different fpm(1) versions things will degrade quickly. Ultimately the targets are just code and fpm(1) is not a compiler. fpm(1) can basically only provide the options the compilers have. So fpm(1) should avoid anything that forces a certain behavior in a way that is not compatible with previous versions as a production tool. It is still not release 1.0 so some acception can be made for that; but changes like this will be too disruptive when a change occurs. So if you use several dependencies you are not in control of that contain fixed-format source and the default is now for all files to be assumed by default to be free-format what will the result be? ---
**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:** [April 7, 2023, 10:32pm UTC](https://fortran-lang.discourse.group/t/fpm-version-0-8-0-released/5520/14 "2023-04-07T22:32:43Z")
> [@urbanjost](#): > > So if you use several dependencies you are not in control of that contain fixed-format source and the default is now for all files to be assumed by default to be free-format what will the result be? Good point. I think this is a separate question about changing defaults (previously I was reacting to just adding features). For changing defaults one robust way to do this is by versioning the `fpm.toml` format itself. Then a newer version can change defaults without breaking older version. @awvwgk I think we should do that, to give us an option to change defaults in the future without breaking things. ---
**Author:** ![urbanjost](https://avatars.discourse-cdn.com/v4/letter/u/0ea827/32.png) [@urbanjost](https://fortran-lang.discourse.group/u/urbanjost)\ **Post date:** [April 8, 2023, 12:10am UTC](https://fortran-lang.discourse.group/t/fpm-version-0-8-0-released/5520/15 "2023-04-08T00:10:31Z")
For any feature that is implemented as a call to a compiler switch I would prefer it be implemented via profiles; but profiles can be implemented up to a point with keywords that are generic, like “implicit-none” that fpm knows the switches for on various compilers. But at some point we need at least something that says “on this OS type” “with this compiler” “for these files” “add this switch”, with possibly a way for the user to define or use other profiles or named groups. Something like ```plaintext profile.myopts = [ { os="linux", compiler="gfortran", flag="-implicit-none -free"}, { os="linux", compiler=["ifx","ifort"], flag="-implicit-none -free", ,link-flag=" " }, { os="*", compiler="*", source-dir="*", name="*.f90", profiles=[fast,traceback]} ] build.options = [ { source-dir="example/old/", name="*.f90", dependency_profile="myopts"} ] ``` So I could say something like -profile myopts and it could find a match or warn there is not one. Not as flexible as calling lua or if/else/endif preprocessing, but for example if “dependency\_profile” were defined as what to do when used as a remote package, and could be applied on a directory and name basis with regular expressions or globbing, and a profile could be defined via other profiles, and we had built-in “profiles” that could be as simple as a single switch like profile “optimize” might be “-O3” then you could specify things like “when this is a dependency build it optimized with these external links added to loader calls” and so. So before too many compiler switches are added as simple names I really think the -profile code should be finished. I lost track so I am not sure where that stands; I thought it was nearly complete a while ago. Some of these changes really amount to making a generic name for a switch. That is not a bad thing. Neither would be creating a generic compiler command that could call a bunch of compilers that fpm could call, modularizing this type of stuff and being a useful tool itself outside of fpm. But we need some method of applying this to specific filenames with load options that can be aggregated from all the dependencies for external resources like MPI or X11 or we cannot scale unless the project is all self-contained. Is there something somewhere that describes where profiles sit, especially how they will work with dependent projects? ---
**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:** [April 8, 2023, 6:00am UTC](https://fortran-lang.discourse.group/t/fpm-version-0-8-0-released/5520/16 "2023-04-08T06:00:12Z")
> [@certik](#): > > For changing defaults one robust way to do this is by versioning the `fpm.toml` format itself. I also believe this is the best way to mitigate manifest compatibility issues, as said above, we’re working on versioning constraints and one of them will be something like: ```toml [dependencies] fpm=">=0.8.0" ``` Which of course will still break compatibility with prior fpm versions that can’t read that syntax, the usual chicken-egg problem, but like said, we will still have to accept some breaking changes in the format until fpm is still alpha ---
**Author:** ![urbanjost](https://avatars.discourse-cdn.com/v4/letter/u/0ea827/32.png) [@urbanjost](https://fortran-lang.discourse.group/u/urbanjost)\ **Post date:** [April 8, 2023, 7:38am UTC](https://fortran-lang.discourse.group/t/fpm-version-0-8-0-released/5520/17 "2023-04-08T07:38:55Z")
Although when initially introduced a simple pre-processor would also have issues with older versions, but going forward it would be far more flexible. There was an ongoing discussion about creating a standard Fortran preprocessor. If there is any progress on it, and it resembles cpp/fpp an implementation just implementing if/else/endif would be easy to implement in Fortran that would be sufficient that could grow into a full implementation of the standard preprocessor and so in the long term kill two birds with one stone. On a more pressing issue. I am getting a huge number of unneeded updates of remote projects. No one is seeing this? It looks like in `manifest_has_changed()` that this comparison is false when the %git for one has a sha1 description but the other has a tag in the comparison ``` if (.not.(this%git==that%git))return ``` So I get a fake false return. For example, building fpm(1) itself sometimes the toml-f descriptions for THIS and THAT are ``` # Git target # - URL https://github.com/toml-f/toml-f # - sha1 54686e45993f3a9a1d05d5c7419f39e7d5a4eb3f # Git target # - URL https://github.com/toml-f/toml-f # - tag v0.4.0 ``` and the comparison returns incorrectly that they are not the same package. No one else has mentioned this so I thought it was because I was building fpm(1) with ifx(1) so I built with gfortran(1) but am still seeing it. Still digging down so not sure yet why the descriptions are getting generated differently for the same package. ---
**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:** [April 8, 2023, 8:15am UTC](https://fortran-lang.discourse.group/t/fpm-version-0-8-0-released/5520/18 "2023-04-08T08:15:17Z")
> [@certik](#): > > Instead, let’s give an error and allow to require a certain fpm version, much like cmake does it. In that case, it’s important to keep track somewhere (in the documentation) of when a feature appeared in fpm. In CMake, they have now made the effort but it was not the case a few years ago and so it was finally difficult to know what version the user really need (as generally you have only one of the latest version on your machine). ---
**Author:** ![HelloThere](https://avatars.discourse-cdn.com/v4/letter/h/9de053/32.png) [@HelloThere](https://fortran-lang.discourse.group/u/HelloThere)\ **Post date:** [April 8, 2023, 8:42am UTC](https://fortran-lang.discourse.group/t/fpm-version-0-8-0-released/5520/19 "2023-04-08T08:42:40Z")
Hi all, I am new here so first of all a big thanks to the developers of fpm. In my work I mainly write programs in Fortran, and fpm has become a real game changer in developing and interfacing different programs and libraries. Today I tried to compile a code with the new version 0.8.0 of fpm. Unfortunately, I have a dependence that does not compile successfully with the new version. I get the error: Error: Procedure ‘a0i’ called with an implicit interface at (1) [-Werror=implicit-interface] f951: some warnings being treated as errors So my general question is if there was a strategic change in dealing with such warnings (now turned into errors)? Can the -Werror flag be turned off somehow in a way that a code that compiles with version 0.7.0 also compiles with version 0.8.0? My apologies if this is not the right place to ask. I wasn’t sure if I should post in this thread or open a new one. ---
**Author:** ![zoziha](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/zoziha/32/582_2.png) [@zoziha](https://fortran-lang.discourse.group/u/zoziha)\ **Post date:** [April 8, 2023, 9:09am UTC](https://fortran-lang.discourse.group/t/fpm-version-0-8-0-released/5520/20 "2023-04-08T09:09:35Z")
This is because `fpm-0.8.0` increases the `[fortran]` feature compared to `0.7.0`. [For details](https://fpm.fortran-lang.org/en/spec/manifest.html#fortran-features), you need to add the following content in `fpm.toml`: ```toml [fortran] implicit-external = true ``` It is true that `fpm` has made great progress, but considering that it has not been released to the version of `1.0.0`, you can try `meson`, which is about to be released to `1.1.0`, and the support for Fortran is also very good and simple enough 🙂 . [Next page](https://fortran-lang.discourse.group/t/fpm-version-0-8-0-released/5520.md?page=2)