Add support for FPM

[gnikit]

The Fortran Package Manager is a package manager and build system for Fortran developed by us. Modern Fortran should natively support it, allow for easy project setup, etc.

In the beginning we can use the ShellExecution task that is already present to spawn instances of fpm, but in the long run we will need to write a CustomExecution task to allow for shared states and a more tailored-made experience

TODO List (to be expanded)

This issue is still in its planning stages, so the TODO list might be expanded

• Typescript API design with fpm
• Spawn fpm in vscode tasks
• Ways for users to interact with FPM e.g. .toml, launch.json, settings.json?
• autodetection of fpm.toml
• Schema support for fpm.toml

CC @everythingfunctional

[fedebenelli]

I'm really interested in this feature, while setting up tasks to interact with fpm ain't that hard, a full integration with vscode will surely be a good thing to ease the process. Some kind of integration with debugging would be nice, too. Right now I only know of three ways of debugging:

• Having a separate Makefile (with it's specific task) to compile the executable to a specific directory and keep a fixed launch.json file.
• Building with fpm and moving the executable to a specific dir (to keep the launch.json file intact).
• Build with fpm and edit the launch.json file to point to the new executable.

Maybe there is a better way that I'm not aware of...

I think that good enough interaction with fpm to both run, debug and test would be awesome.

EDIT: Forgot to say, I don't have experience on building VSCode extensions, but I'm up to help with at least testing and brainstorming (maybe I'll also try to learn a bit about building extensions)

[gnikit]

Hi @fedebenelli thanks for the interest in this issue, I haven't had a lot of time to think about how we will best implement this. My original thoughts were to offer some high level integration for building targets (similar to CMake), you wouldn't need to explicitly set build tasks in launch.json.

For debugging I would suspect an out of source debug installation would be what you are looking for, so your debug targets would not affect your optimised targets. My workflow in general is me using debug mode and if I need to run with optimisations enabled I will reconfigure and recompile.

If you have any ideas or suggestions feel free to post them on this issue. Later this summer I will be opening a thread on Fortran Discourse to get some ideas about how the UI should look like.

[ivan-pi]

You may want to keep an eye on the discussion at fortran-lang/fpm#479

I've shown a basic example of fpm in Sublime (fortran-lang/fpm#479 (comment)) and @plevold has demonstrated it for VS Code (fortran-lang/fpm#479 (comment)). It works best if you have your code open as a "Project". In this case, you can easily run fpm in the top folder containing the manifest.

I think it's good to adopt a co-design strategy, meaning if there is something VS Code needs, we can see to add it in fpm.

[gnikit]

Thanks for the heads up @ivan-pi. I have gone ahead and subscribed into the discussion. That is a very good start indeed. My idea behind this is to have a slightly higher level interface, closer to that of CMake, with a SideBar menu (I don't think they are called that) and native integration with the linter.

[radekg]

Awesome to see this here. I have stumbled on the issue related to fpm + this extension: fortran-lang/fpm#732.

It would be great if the Modern Fortran extension picked up the build/ directory as the mod files directory when fpm.toml file is found in the project's root.

A question, in the meantime, is there a way to configure this vsc extension to always store mod files in build/, and pick them up from the same directory?

[gnikit]

You can set your global vscode setting call modOutputDir (I think) to be something like ${workspaceFolder}/build that should both store your .mod files in build/ and include the path to the linter (gfortran should do that by default)

[radekg]

You can set your global vscode setting call modOutputDir (I think) to be something like ${workspaceFolder}/build that should both store your .mod files in build/ and include the path to the linter (gfortran should do that by default)

Mmmm, this works but I need to hard-code that gfortran_... directory, too. Surprisingly, the 2A42023B310FA28D part is constant across different projects. I guess that will be sufficient for me. Thank you!

[gnikit]

Fpm can run additional commands to the shell by passing them after the fpm specific commands e.g. fpm build -- find build -name '*.mod' -exec cp {} ./build/include ;

You could define in a build task or a series of them that will accomplish what you want. I think I posted somewhere in the fpm discussions a series of tasks.json and launch.json files that get vscode to build and debug fpm built codes.

What you are effectively trying to do is what this issue is about. Working out that hash is part of the problem. There was a discussion in fpm about making the paths somewhat deterministic so tools would be able to access builds.

Basically this issue is still on brainstorming stage about how to implement the vscode integration.

[gnikit]

Again, the additional command I posted will not work, since you might be copying .mod files from outdated or unrelated builds. The easiest way we found was to install the package and it's mod files into some temporary location for vscode to access.

[radekg]

Thank you, I will look into those when time allows. I’m learning Fortran for fun, pretty cool so far.

[gnikit]

I am glad to hear that, if you want any help don't hesitate to reach out here or in our Fortran Discourse https://fortran-lang.discourse.group/