Fpm version 0.6.0 released

We just released version 0.6.0 of the Fortran package manager (fpm).

This release introduces a better visualization for the build output, the compiler output is only shown on error to keep the standard output clean for successful builds. Furthermore, fpm can now detect unused modules and avoids compiling modules that are not needed for an application, which improves the compilation speed with large dependencies like stdlib. Fpm can now also compile projects with a C main, i.e. it is now also a C package manager. A new command was added to remove build artifacts via the clean command, no need to manually delete the build directory anymore.

When creating a new project with fpm the author information are now taken from the git configuration to avoid using placeholders in the manifest. Also the new command for backfilling will work now when inside an existing fpm directory with fpm new . --backfill.

Plenty more improvements and bugfixes went into this release, thanks to eleven contributors sending patches for this release. Checkout the release notes:

The version is up on conda-forge already and the fortran-lang homebrew tap. Updates for MSYS2 and Spack are submitted and awaiting review.

16 Likes

Great job to all who contributed!

I was curious, is there a way to specify the minimum version of fpm needed to build a project? I suspect this would be useful to detect if your fpm.toml can be used for with your from version.

1 Like

Currently there is not. It could be useful to have a version constraint on fpm, this also means fpm must track at which point a new feature in the package manifest is introduced in some way. Otherwise we end up with a situation like in CMake, where you can add a minimum required version, but unless you actually build with the minimum version there is no way to know whether it actually works as expected (which is to be honest more harmful than not having such an option).

1 Like

A huge thank you to all the contributors! :clap:

This is a very significant improvement in the user experience. I think you’re getting quite close now to beta-level features and quality :wink:

3 Likes

The MSYS2 repo now ships 0.6.0 as well: Base Package: mingw-w64-fpm - MSYS2 Packages. That was really fast.

3 Likes

Thanks to the fpm dev team. I’ve started using it in my project and it really is a great tool!

3 Likes

I have asked my sysadmins to update the fpm installation on our HPC cluster from 0.2.0 to 0.6.0 but they are facing some issues.

Their first choice was to use spack but they get an error “Error: Package ‘fpm’ not found”. I’m not familiar with spack, is there a specific repository they should use?

Second attempt was use the bootstrapping install script from the GitHub repository, which I had successfully done for 0.5.0 on my local install. But that option is now giving an error “no commits present in branch ‘master’”. Same error with ‘fpm update’ from version 0.5.0. I’m thinking this might be due to the change in naming the default branch in git? If that’s the case is there any fix other than updating git? Or any suggestions on how to go forward?

What OS/distro is your HPC cluster? The relase page - Release Fpm version 0.6.0 · fortran-lang/fpm · GitHub - has a pre-built binary for x86_64 Linux.

You could also download the pre-built binary yourself by doing

mkdir -p ~/bin && wget https://github.com/fortran-lang/fpm/releases/download/v0.6.0/fpm-0.6.0-linux-x86_64 -O ~/bin/fpm

Make sure ~/bin is on your PATH and if it isn’t add it by doing export PATH=~/bin:$PATH in your .bashrc or equivalent shell config file. Maybe I’m the unlucky one, but asking HPC sysadmins to do something has never led to any good in my life :frowning_face:

CentOS 7

I haven’t tried the prebuilt binaries, will check thanks. I guess they’ll need an install mechanism to automate the modules builds in the system. Not an expert in that domain really.

It sounds like you might be using an old version of the bootstrap script. Can you try downloading the latest one from here and see if that works?

hi @lkedward. I am not sure, I cloned a fresh copy of the repository and launched the install script from there. At first sight it seems that same script you linked.

Will give it one more try tho…

mkdir _scratch  # make a scratch directory to use for the build
cd _scratch
wget   https://raw.githubusercontent.com/urbanjost/index/main/bootstrap/fpm.F90
gfortran -o fpm fpm.F90
printenv PATH  # show your PATH variable and pick a directory in your path to move the executable to
cp fpm ~/.local/bin  # for example; or make and ~/bin as described as above

assume “printenv SHELL” is bash (or fish, sh, …) and that you have a recent version of gfortran.

That builds it from a single source file. If that does not work, what does

uname -a
gfortran --version

display; should build with ifort at a minimum as well.

PS:
I like to add the option “-static” to the compile, personally.

So I’ve double checked and I am actually using the the latest script. To add some details here is what I’m doing for the bootstraping:

git clone git@github.com:fortran-lang/fpm.git
cd fpm 
./install.sh

And this is the output I get

  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
100  892k  100  892k    0     0  1579k      0 --:--:-- --:--:-- --:--:-- 1579k
fpm.F90:3405:0:

    path=adjustl(path//'  ')

Warning: ‘__builtin_memset’: specified size 18446744073709551614 exceeds maximum object size 9223372036854775807 [-Wstringop-overflow=]
/tmp/ccfF6cY1.o: In function `__fpm_filesystem_MOD_get_temp_filename':
_tmp/fpm/build/bootstrap/fpm.F90:10050: warning: the use of `tempnam' is dangerous, better use `mkstemp'
fatal: your current branch 'master' does not have any commits yet
<ERROR>Error while retrieving commit information
STOP 1
$ git --version
git version 2.29.2

thanks, I agree that this is a good method for the ~/.local/bin installation.

More in general, here I’m looking for a mechanism that allows easy software updates without the need of having to know how to compile fortran code or think about compiler flags. That is just because the use case is on a cluster managed through users submitting tickets and the admins might not know any fortran and might have very different levels of experience with building fortran applications.

Ideally spack would be the best in our case because I believe that’s the package manager generally used for most of the system modules. Bootstrapping already requires more experienced admins to get involved and makes the update slower (and team mates less likely to request it choosing the least resistance path and just going for a local install that then does not allow sharing tools within the teams).

FWIW we have only managed to build a system module for fpm from the pre-built binaries but not to solve that error or use spack.

The updated user experience looks very good and to people used to spend time building with Makefiles for small projects seeing this for the first time looked like magic.

Thanks for the extra info, it looks like the bootstrapping script is working, but fpm is then failing to fetch it’s own dependencies. This may be a bug with fpm and older versions of Git perhaps?

With your fpm system module, are you able to compile fpm projects that have dependencies?

I thought so too at first, but I’ve managed to run the bootstrapping script successfully on an ubuntu docker environment with an even older version of git.

Yes I am able to add stdlib as a dependency and build the project with the module based on the compiled binaries.

And now I just tested again the bootstrapping is now working, but my version of git has not changed. Assuming nothing has changed in the dependencies themselves I can only imagine that there was something broken with my system (git installation?) which has been fixed in the meanwhile.

2 Likes