Setting up a generic launch.json for Rust in VSCode [SOLVED]

Hello, I have the following structure for my fledgling Rust work...

~/code/rust --+
..............|
..............+-- .vscode
..............|
..............+-- foo
..............|
..............+-- guessing_game
..............|
..............+-- hello_cargo
..............|
..............+-- tutorial

Within the .vscode folder is a launch.json file which I would like to use as a generic file for all of my Rustlang folders.

Each folder has the src folder where the Rustlang source file is, and also a target folder with the usual debug, release and doc folders.

I have my vscode workspace set to ~/code/rust and I would like to set up my launch.json with the necessary macros to expand generically according to which source file is open at the time.

I am aware that I can get the full path of the source using the ${file} macro but of cource the debug folder is in a parallel structure to the src folder. How can I build a generic reference to the debug folder?

If the worst comes to the worst, I'll keep a separate launch.json for each Rustlang project and hard code the paths therein, but obviously I would prefer to use the shared launch.json file.

Any ideas, anyone?

2 Likes

So, my launch.json now looks like this...

{
    "version": "0.2.0",
    "configurations": [
        {
            "type": "lldb",
            "request": "launch",
            "name": "Debug",
            "program": "${fileDirname}/../target/debug/${fileBasenameNoExtension}",
            "args": [],
            "cwd": "${workspaceRoot}",
            "sourceLanguages": [
                "rust"
            ]
        }
    ]
}

and my cargo.toml looks like this...


[package]
name = "guessing_game"
version = "0.1.0"
authors = ["carlca <carl.caulkett@gmail.com>"]

[dependencies]
rand = "0.3.14"

[[bin]]
name = "guessing_game"
path = "src/guessing_game.rs"

The only manual change I have to make is to rename the default main.rs that the cargo new <name> produces, and to add the [[bin]] section to the cargo.toml file. Both these tasks can and will be done by a shell script which I will do tomorrow, as it is getting late here!

1 Like

The aforementioned shell script looks like this...

#!/usr/bin/env bash
cd ~/code/rust
cargo new $1 --bin
mv ~/code/rust/$1/src/main.rs ~/code/rust/$1/src/$1.rs
echo "" >> ~/code/rust/$1/cargo.toml
echo "[[bin]]" >> ~/code/rust/$1/cargo.toml
echo "name = \"$1\"" >> ~/code/rust/$1/cargo.toml
echo "path = \"src/$1.rs\"" >> ~/code/rust/$1/cargo.toml

I've called it rs_new.sh and I have an alias rs_new pointing to it. All I have to do now is to run rs_new <name> and it makes a <name>.rs which can be built and debugged in VSCode. Anyone wanting to use this may have to change the path names to suit, and I'm sure that because of my lack of experience in Rustlang matters, I will no doubt come up against a glaring deficiancy in this little project. But, it will do for me for now!

Renaming main.rs with a script seems unnecessary: as it's written here, you can just use

"program": "${workspaceRoot}/target/debug/${workspaceRootFolderName}",

So if you have a guessing_game project it'll result to "target/debug/guessing_game".

Thanks, but my solution has the distinct advavantage of actually working with the directory structure described in the tweet, while the suggestion above fails!

Oh, you want to keep one physical .vscode in the parent directory. Sorry, missed that.

Wouldn't it be simpler to use your shell script to copy .vscode/lunch.json into new project's dir? This way you don't need to mangle Cargo.toml.

Btw, do you really need a special launch.json for debugging? vscode seems to create them on the fly when required, seems to work:

This solution works for me, without any change in the code.

    {
      "type": "lldb",
      "request": "launch",
      "name": "Debug Rust",
      "cargo": {
        "args": ["build", "--manifest-path", "${fileDirname}/../Cargo.toml"]
      }
    }
3 Likes

This is excatly what I was looking for. By specifying the manifest path as shown, I am able to compile projects that are subprojects of a larger git tree.