Integrating fpm with text editors (Sublime, Atom, VS Code)

[ivan-pi]

Many modern text editors have shortcuts for building or running a program. For example in my favorite editor - Sublime, one can use the following build system scripts:

Build

{
"cmd" : ["/usr/local/bin/gfortran ${file_name} -o ${file_base_name}.out"],
"selector" : "source.f90",
"working_dir" : "${file_path}",
"shell" : true
}

Build and run

{
"cmd" : ["/usr/local/bin/gfortran ${file_name} -o ${file_base_name} && ./${file_base_name}"],
"selector" : "source.f90",
"working_dir" : "${file_path}",
"shell" : true
}

The default build option is accessed using Ctrl + B, while more control over the build system script option can be selected using Ctrl + Shift + B.

The scripts above only work for a single main program. I imagine with fpm it should be possible to build a program at any location in the source tree with the right commands.

One problem I see is how does fpm figure which is the top level directory, where the fpm.toml is located. One option could be to prepend each source file with some identifier, or recursively search the higher level directories until one of them contains the fpm.toml file.

Ideally, we could try to offer packages for the editors, that users can easily install and gain access to.

What are your thoughts on this?

[LKedward]

One problem I see is how does fpm figure which is the top level directory, where the fpm.toml is located. One option could be to prepend each source file with some identifier, or recursively search the higher level directories until one of them contains the fpm.toml file.

Searching higher-level directories like git seems like a good way to go as also discussed in this issue: #172

[ivan-pi]

Assuming #172 is resolved, then I believe it should be easy to get it to work for executable targets.

For any other source file I guess it makes sense to build only the library. Do you think that is possible with the current command-line options? Of course this might differ between text editors, depending on how tightly they integrate a shell.

In other words, I would like to determine if any new fpm commands might be necessary.

[ghost]

This is a great idea. I would also like to see extensions for Atom and Visual Studio Code, perhaps integrated with fpm GUI (https://fortran-lang.discourse.group/t/experimenting-with-a-gui-for-fpm/1186).

[arjenmarkus]

Last year, there was a presentation on the integration of Visual Studio Code for Fortran during the conference. I would have dig a bit in the archives who did the presentation, but the idea of further integration with such tools is definitely worthwhile. Op wo 26 mei 2021 om 14:16 schreef Carlos Une ***@***.***>:

…

This is a great idea. I would also like to see extensions for Atom and Visual Studio Code, perhaps integrated with fpm GUI ( https://fortran-lang.discourse.group/t/experimenting-with-a-gui-for-fpm/1186 ). — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#479 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAN6YR4PS35BTBII64RRR23TPTRBRANCNFSM45R4ACLQ> .

[ivan-pi]

In the FortranCon 2020 archive I was only able to find the Code::Blocks presentation (the Code::Blocks Fortran plugin page is located here).

[arjenmarkus]

Oh, then I misremembered it - but now you mention it, it was indeed Code::Blocks. (Visual Studio Code has been gaining interest in my company/institute). Op wo 26 mei 2021 om 15:56 schreef Ivan Pribec ***@***.***>:

…

In the FortranCon 2020 archive I was only able to find the Code::Blocks <https://tcevents.chem.uzh.ch/event/12/contributions/41/attachments/41/114/CodeBlocks_DariusMarkauskas.pdf> presentation (the Code::Blocks Fortran plugin page is located here <https://cbfortran.sourceforge.io/>). — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#479 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAN6YR3CJTG3UAWR5TDIHWLTPT4ZFANCNFSM45R4ACLQ> .

[plevold]

Adding this to .vscode/tasks.json in a repo with a fpm project works quite nicely for VSCode:

{
    // See https://go.microsoft.com/fwlink/?LinkId=733558
    // for the documentation about the tasks.json format
    "version": "2.0.0",
    "tasks": [
        {
            "label": "Build with FPM",
            "command": "fpm",
            "args": [
                "build"
            ],
            "group": {
                "kind": "build",
                "isDefault": true
            }
        },
        {
            "label": "Run Tests",
            "command": "fpm",
            "args": [
                "test"
            ],
            "group": {
                "kind": "test",
                "isDefault": true
            }
        }
    ]
}

The commands "Tasks: Run Build Task" and "Tasks: Run Test Task" from the ctrl+shift+P command palette can then be used to invoke fpm. The default command can be set using "Tasks: Configure Default Build/Test Task".

[ivan-pi]

@everythingfunctional just released a plugin for the Atom Editor. More information can be found at Discourse: https://fortran-lang.discourse.group/t/fpm-plugin-for-atom-editor/1747

The sources for the plugin are available on GitHub: https://github.com/everythingfunctional/atom-build-fpm

An earlier thread also contains a plugin for Visual Studio: https://fortran-lang.discourse.group/t/fortran-package-manager-fpm-for-visual-studio/1346

Thanks Brad for doing the work! I believe Atom and VS Code share some similarities, maybe you could join forces with @plevold?

[everythingfunctional]

I haven't started looking into VSCode yet (it's next on my list), but my understanding is that it is very similar to Atom. I wasn't aware anybody else was working on anything, but I'd be happy to have any help maintaining these and developing more that anybody would be willing to provide. @plevold , if you're interested just let me know.

[plevold]

To say that I'm "working on it" is perhaps a bit of an exaggeration... 😄 The suggestion I posted earlier configures the Tasks functionality in VSCode to run fpm commands for building and testing.

An extension could probably provide a much more integrated and easy to use experience in VSCode though so that would be great to see. Unfortunately I don't know anything about VSCode extension development, but I'm more than happy to beta test if anyone is making one.

[ivan-pi]

So it turns out the Build Systems API in Sublime made it pretty easy to map the basic fpm commands.

Essentially, Sublime will search for the keyfile fpm.toml and then invoke a command in the working directory which is set to the project path (this requires users to open their file in Sublime's project mode). Pressing Ctrl + Shift + B will open a drop-down menu of available commands. The last build command can be repeated with Ctrl + B.

fpm.sublime-build:

{
	"keyfiles": ["fpm.toml"],
	"working_dir": "$project_path",
	"variants":
	[
		{
			"name": "Build (debug)",
			"cmd": ["fpm", "build", "--profile", "debug"]
		},
		{
			"name": "Build (release)",
			"cmd": ["fpm", "build", "--profile", "release"]
		},
		{
			"name": "Test (debug)",
			"cmd": ["fpm", "test", "--profile", "debug"]
		},
		{
			"name": "Test (release)",
			"cmd": ["fpm", "test", "--profile", "release"]
		},
		{
			"name": "Help",
			"shell_cmd": "fpm help"
		}
	]
}

I'm still figuring out what is the best way to map the run command for an app file in active view. One problem I foresee is if the app target name (specified in the manifest) and source file name don't match (one reason to stick with matching names).

In it's basic version, the Sublime Build Systems API only performs expansion of the following variables:

Variables (click to expand)

Variable	Description
$packages	The path to the Packages/ folder.
$platform	The platform Sublime Text is running on: "windows", "osx" or "linux".
$file	The full path, including folder, to the file in the active view.
$file_path	The path to the folder that contains the file in the active view.
$file_name	The file name (sans folder path) of the file in the active view.
$file_base_name	The file name, exluding the extension, of the file in the active view.
$file_extension	The extension of the file name of the file in the active view.
$folder	The full path to the first folder open in the side bar.
$project	The full path to the current project file.
$project_path	The path to the folder containing the current project file.
$project_name	The file name (sans folder path) of the current project file.
$project_base_name	The file name, excluding the extension, of the current project file.
$project_extension	The extension of the current project file.

Their is an advanced API which allows much more complex commands: accepting user input (e.g. for options), suggesting completions, etc. - but it requires writing a Python plugin. Presumably one would first write a Python class shadowing all the fpm commands.

(Caveat: the built-in terminal where Sublime runs your build system command does not accept any user input. The only way you can communicate with your app is through an external file. For interactive input it's necessary to launch an independent Terminal instance, using a package like Terminus. Furthermore if your program uses write or print statements, depending on how your compiler/platform implement buffering, you might not see any output until the program finishes.)

[fedebenelli]

Something that I can't still figure out how to do is to automate the debugging process inside VSCode (with fpm). Right now I build the executable into a specific folder and have set up the launch.json file like below. If there is a way for fpm to show the executable folder I guess it would be enough

{
  // Use IntelliSense to learn about possible attributes.
  // Hover to view descriptions of existing attributes.
  // For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
  "version": "0.2.0",
  "configurations": [
  {
      "name": "(gdb) Fortran",
      "type": "cppdbg",
      "request": "launch",
      "program": "${workspaceFolder}/bin/debuggable",
      "args": [], // Possible input args for the exectuable
      "stopAtEntry": true,
      "cwd": "${workspaceFolder}/bin",
      "externalConsole": false,
      "MIMode": "gdb",
      "setupCommands": [
        {
          "description": "Enable pretty-printing for gdb",
          "text": "-enable-pretty-printing",
          "ignoreFailures": true
        }
      ],
      "preLaunchTask": "make debug"
    }
  ]
}

[gnikit]

fpm is enforcing the --runner keyword to ensure the binary that is used is always up-to-date with the source code, if you were using a path from the build directory, how can you be sure that it is not a stale build you are trying to debug.

I will admit that I don't know enough about fpm to understand why that is an issue. What I am suggesting is that the build path should be something "predictable" and "deterministic" to allow for tools to integrate with fpm (or provide a straightforward way to make the build path predictable and deterministic). It is the user's responsibility to use fpm the way that is intended and not directly use the build binary if they haven't recompiled. Outputting your build to ./build/tmp/bin and having it update whenever you call fpm run, or test to me does not sound unreasonable. Many package managers like npm, yarn and bundlers like webpack and gulp do exactly this. They output the binary in a user-defined path and to address concerns about outdated versions in addition to normal compilation and they also have watchers (they all call npx under the hood). This is basically how I develop the VS Code extension.

I think it's cool that fpm allows for other programs to run through it, but ideally that should be a two-way street. Not all programs, e.g. VS Code, make sense or can be spawned with --runner, so spawning fpm from VS Code before a debug adapter is launched would be useful. There are certainly some options that we can explore in this area, e.g.

• fpm spawning gdb and VS Code attaching to the PID
• passing options through --

[awvwgk]

Outputting your build to ./build/tmp/bin and having it update whenever you call fpm run, or test to me does not sound unreasonable.

I think this clashes with the fundamental principle in fpm for supporting multiple compilers, which is one of the central design goals. The internal build names allow to have several builds of different compilers with fpm. Having a ./build/tmp/bin for the last invoked build might be possible, however this is in conflict with the design goal to not having any lingering state in the build directory. fpm run will rebuild artifacts if necessary, if there were stale artifacts in ./build/tmp/bin would we rebuild the last configuration in use or just the default?

I'm not opposed to introduce some simple state which makes life easier for external tool developers and fpm users, but we should avoid creating something like the CMakeCache.txt which can lead to hard to repair build directories and is resolved by purging the complete build.

Before we further derail this thread, let's maybe open a new issue to continue this discussion on predictable output paths and cached tool chain settings in fpm.

[ivan-pi]

Admittedly, I don't understand all aspects of fpm or VS code integration, but my feeling is that editors and IDE's might be better served by a different interface to fpm than the fpm-CLI.

I say this based on how easy it was to integrate fypp (a Python module) with Sublime which provides a Python API for extensions.

[gnikit]

@fedebenelli Have a look and tell me if these work for you. The fpm: install/(gdb) Launch debugs the binary under main and fpm: test Single File/(gdb) Launch Test will compile and attach a debugger to the opened and in focus Fortran file within ./test

tasks.json

{
  // See https://go.microsoft.com/fwlink/?LinkId=733558
  // for the documentation about the tasks.json format
  "version": "2.0.0",
  "tasks": [
    {
      "label": "fpm: install",
      "type": "shell",
      "command": "fpm",
      "args": [
        "install",
        "--profile",
        "debug",
        "--prefix",
        "${workspaceRoot}/build/vscode"
      ],
      "group": {
        "kind": "build",
        "isDefault": true
      }
    },
    {
      "label": "fpm: test Single File",
      "type": "shell",
      "command": "fpm",
      "args": [
        "test",
        "--target",
        "${fileBasenameNoExtension}",
        "--profile",
        "debug",
        "--runner",
        "cp",
        "--",
        "${workspaceFolder}/build/vscode/test/"
      ],
      "group": {
        "kind": "test",
        "isDefault": true
      },
      "dependsOn": ["Copy Directory Structure"],
      "dependsOrder": "sequence"
    },
    {
      "label": "Copy Directory Structure",
      "type": "shell",
      "options": { "cwd": "${workspaceFolder}/test" },
      "linux": {
        "command": "find",
        "args": [
          ".",
          "-type",
          "d",
          "-exec",
          "mkdir",
          "-p",
          "--",
          "${workspaceRoot}/build/vscode/test/{}",
          "\\;"
        ]
      }
    }
  ]
}

launch.json

{
  // Use IntelliSense to learn about possible attributes.
  // Hover to view descriptions of existing attributes.
  // For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
  "version": "0.2.0",
  "configurations": [
    {
      "name": "(gdb) Launch",
      "type": "cppdbg",
      "request": "launch",
      "program": "${workspaceFolder}/build/vscode/bin/first_steps",
      "args": [],
      "stopAtEntry": false,
      "cwd": "${fileDirname}",
      "environment": [],
      "externalConsole": false,
      "MIMode": "gdb",
      "setupCommands": [
        {
          "description": "Enable pretty-printing for gdb",
          "text": "-enable-pretty-printing",
          "ignoreFailures": true
        },
        {
          "description": "Set Disassembly Flavor to Intel",
          "text": "-gdb-set disassembly-flavor intel",
          "ignoreFailures": true
        }
      ],
      "preLaunchTask": "fpm: install"
    },
    {
      "name": "(gdb) Launch Test",
      "type": "cppdbg",
      "request": "launch",
      "program": "${workspaceFolder}/build/vscode/${relativeFileDirname}/${fileBasenameNoExtension}",
      "args": [],
      "stopAtEntry": false,
      "cwd": "${workspaceFolder}/build/vscode/test",
      "environment": [],
      "externalConsole": false,
      "MIMode": "gdb",
      "setupCommands": [
        {
          "description": "Enable pretty-printing for gdb",
          "text": "-enable-pretty-printing",
          "ignoreFailures": true
        },
        {
          "description": "Set Disassembly Flavor to Intel",
          "text": "-gdb-set disassembly-flavor intel",
          "ignoreFailures": true
        }
      ],
      "preLaunchTask": "fpm: test Single File"
    }
  ]
}

[fedebenelli]

@fedebenelli Have a look and tell me if these work for you. The fpm: install/(gdb) Launch debugs the binary under main and fpm: test Single File/(gdb) Launch Test will compile and attach a debugger to the opened and in focus Fortran file within ./test

tasks.json

{
  // See https://go.microsoft.com/fwlink/?LinkId=733558
  // for the documentation about the tasks.json format
  "version": "2.0.0",
  "tasks": [
    {
      "label": "fpm: install",
      "type": "shell",
      "command": "fpm",
      "args": [
        "install",
        "--profile",
        "debug",
        "--prefix",
        "${workspaceRoot}/build/vscode"
      ],
      "group": {
        "kind": "build",
        "isDefault": true
      }
    },
    {
      "label": "fpm: test Single File",
      "type": "shell",
      "command": "fpm",
      "args": [
        "test",
        "--target",
        "${fileBasenameNoExtension}",
        "--profile",
        "debug",
        "--runner",
        "cp",
        "--",
        "${workspaceFolder}/build/vscode/test/"
      ],
      "group": {
        "kind": "test",
        "isDefault": true
      },
      "dependsOn": ["Copy Directory Structure"],
      "dependsOrder": "sequence"
    },
    {
      "label": "Copy Directory Structure",
      "type": "shell",
      "options": { "cwd": "${workspaceFolder}/test" },
      "linux": {
        "command": "find",
        "args": [
          ".",
          "-type",
          "d",
          "-exec",
          "mkdir",
          "-p",
          "--",
          "${workspaceRoot}/build/vscode/test/{}",
          "\\;"
        ]
      }
    }
  ]
}

launch.json

{
  // Use IntelliSense to learn about possible attributes.
  // Hover to view descriptions of existing attributes.
  // For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
  "version": "0.2.0",
  "configurations": [
    {
      "name": "(gdb) Launch",
      "type": "cppdbg",
      "request": "launch",
      "program": "${workspaceFolder}/build/vscode/bin/first_steps",
      "args": [],
      "stopAtEntry": false,
      "cwd": "${fileDirname}",
      "environment": [],
      "externalConsole": false,
      "MIMode": "gdb",
      "setupCommands": [
        {
          "description": "Enable pretty-printing for gdb",
          "text": "-enable-pretty-printing",
          "ignoreFailures": true
        },
        {
          "description": "Set Disassembly Flavor to Intel",
          "text": "-gdb-set disassembly-flavor intel",
          "ignoreFailures": true
        }
      ],
      "preLaunchTask": "fpm: install"
    },
    {
      "name": "(gdb) Launch Test",
      "type": "cppdbg",
      "request": "launch",
      "program": "${workspaceFolder}/build/vscode/${relativeFileDirname}/${fileBasenameNoExtension}",
      "args": [],
      "stopAtEntry": false,
      "cwd": "${workspaceFolder}/build/vscode/test",
      "environment": [],
      "externalConsole": false,
      "MIMode": "gdb",
      "setupCommands": [
        {
          "description": "Enable pretty-printing for gdb",
          "text": "-enable-pretty-printing",
          "ignoreFailures": true
        },
        {
          "description": "Set Disassembly Flavor to Intel",
          "text": "-gdb-set disassembly-flavor intel",
          "ignoreFailures": true
        }
      ],
      "preLaunchTask": "fpm: test Single File"
    }
  ]
}

Sorry for the late reply! Thank you so much! this is exactly what I wanted!