Congratulations and thanks to the maintainers and contributors for another great release!
New version is already up on conda-forge for Linux (x86_64, ppc64le and aarch64) and MacOS (x86_64 and aarch64):
conda create -n fpm-0.4.0 fpm conda activate fpm-0.4.0
I also updated my homebrew tap for fpm:
brew tap awvwgk/fpm brew install fpm
Still have to update my fpm
PKGBUILD for MSYS2.
Just a note that the macOS / ARM version does not work: Fails to run on macOS / ARM · Issue #7 · conda-forge/fpm-feedstock · GitHub.
If anybody has time to investigate, that would be awesome.
I think this is a good time to get fpm into a package manager for Windows, conda-forge is currently lacking a bit on this side, therefore I submitted my MinGW PKGBUILD to the MSYS2 repository:
Similarly, we could think about contributing a formula for fpm to homebrew-core, this would provide a natively built MacOS/ARM binary as well. While I’m maintaining a tap for fpm, I’m not really interested in contributing to homebrew-core, since I’m not actually a user of brew. Do we have Mac users here, which are using brew and are interested in contributing there?
Perfect! I was investigating how to install fpm on Windows, for now I’ll try the binary from here: Release Fpm alpha version 0.4.0 · fortran-lang/fpm · GitHub and see if everything work at the CI.
Fpm is now available in MSYS2 for Windows: Base Package: mingw-w64-fpm - MSYS2 Packages. On Windows you should now be able to install fpm with pacman using:
pacman -S mingw-w64-x86_64-fpm
For anyone interested, I described the process of packaging (with) fpm in
Fpm is now available in spack: Package List — Spack 0.16.2 documentation
From the latest spack develop version you can now
spack install fpm +openmp spack load fpm +openmp
Thanks @awvwgk for creating the spack package! Unfortunately I can’t test it right now, as Spack does not work on my macOS (Installation issue: gcc · Issue #25598 · spack/spack · GitHub), but at least I looked how it is done. Here is the spack source code:
It seems the main code is in
which uses fpm 0.3.0 that was distributed as a single file, to bootstrap the most rerent version.
I think this works for now, but I think this will eventually break once
fpm (as a package) uses some feature not supported by the 0.3.0 version. I guess we could then do a two step bootstrap, to first bootstrap a version of
fpm that still builds with 0.3.0, and then use that to bootstrap the latest version (or even do multiple steps).
However, I think I want to finish Allow to generate a standalone tarball with all dependencies · Issue #123 · fortran-lang/fpm · GitHub, which should allow a super simple and robust bootstrap. Just a simple tarball with a cmake build system.
Alternatively, as a separate capability, being able to generate a single file (with all the dependencies correctly ordered) would also be very helpful, I think it can be done automatically. One issue is that we also require some C files to compile I believe.
But until then I think the above approach works.
Bootstrapping with the single source file version seems quite robust so far and the idea is simply genius (thanks to John @urbanjost) because it reduces our dependency footprint to only a Fortran compiler (no C compiler at this stage).
Regarding the install script, we usually update the install script after the release, to use a newer single source version. Therefore, the install script will always have a “matching pair” of fpm versions that can compile each other available.
Unfortunately, we can’t yet use the same version as the release for bootstrapping, because the single source version is still created manually after the release. This should be automated, but since I have to modify the package manifest to remove all test targets before running the script this is currently not possible in an automated way. We need Behavior of `fpm build` and `fpm test` · Issue #92 · fortran-lang/fpm · GitHub resolved first.
Also, the CI testing fpm itself is still using fpm 0.2.0 for bootstrapping the latest commit, which helps to retain some backwards compatibility between the versions. Once we break this in our CI, we will notice it immediately.
In summary, I don’t see this as an issue at the moment. In the future we might adjust the install script to use another bootstrap mechanism, but as long as the script knows how to bootstrap and install fpm, we should be fine.
@awvwgk we should test the single file bootstrap at our CI, using the master version of
fpm only (use the master version to create a single file, compile, and use it to build
fpm). As long as that works, then I think there is no problem.
Just setup a workflow for this at fpm:
@awvwgk good stuff, I already approved the PR. I think with the PR in, this bootstrap problem is completely fixed. Really well done. Thank you.
A great thing about fpm is that it installs in
Yesterday, I tried to install it on a distant machine where I have no admin rights and it worked immediately! Although it may seem obvious for you, I was personally delighted! That’s an important feature I was not fully aware of.