about
04/13/2022
RustBites - Tooling
Code Repository Code Examples Rust Bites Repo

Rust Bite - Tooling

Development tools for Rust

1. Prologue

In this Bite we look at processes for building programs and software systems using Rust. The intent is to provide build processes for both Windows and Linux platforms. One major ingredient is to use Visual Studio Code as a code editor on both OS platforms. VS Code supports plugins for Rust that provide intellisense and error flags. It also provides a contained terminal window we will use to initiate builds from the command line and executions of successful build products.

2. Visual Studio Code Editor:

Figure 1. VS Code IDE Installation: Download Visual Studio Code, a.k.a. VS Code. This works for Windows, Linux, and macOS. Then run installer from Downloads folder. IDE Setup: There are two things you may wish to change in the default configuration:
  1. The terminal panel, Figure 1 on the right, is placed by default at the bottom of the IDE window. It works better for me to have in on the right. You can place it wherever you like with settings (click Gear icon at left bottom -> settings):
    Settings -> User -> Workbench -> Panel Default Location
  2. By default the IDE shows a code Minimap on the right of the code editing panel. You can disable that with:
    Settings -> User -> TextEditor -> Minimap
You will find it convenient to use the key board shortcuts:
  • "ctrl /" to toggle comments on selected lines
  • "ctrl [ and ctrl ]" to control indenting of selected lines
  • Also, to open integrated terminal in any folder, right click any file in the folder and select "Open in Integrated Terminal". This is particularly useful when you open a workspace folder (any folder with .vscode subfolder).
Other Settings: To change other settings:
  • "settings -> Editor -> uncheck Accept Suggestion on Commit Character" to avoid many spurious insertions of unwanted suggestions.
  • "settings -> search for menu -> select Menu Bar Visibility" to show/hide top menu
  • "F11" to toggle full screen mode
  • "View -> Command Palette -> .Net: Generate Assets for Build and Debug" enables Run -> Start Debugging. Have to have editor open in project directory.
  • "ctrl K, ctrl T -> select editor theme" to select one of many alternatives
  • "settings -> workbench -> appearance -> color customizations" to set terminal colors
  • "File -> Preferences -> Settings" to change lots of defaults
  • "File -> Preferences -> Settings -> user -> Features -> Terminal" to change Terminal defaults
  • "View -> Command Pallet -> Preferences: Open Settings (JSON)" to edit any user setting you've changed
Settings Details
Figure 4. VS Code Project launch Settings Figure 5. VS Code User Settings The settings you will manage most often are local settings for each project, found in a .vscode folder at the top level of your project. Initially that folder doesn't exist, and you don't need to explicitly create it. VS Code creates it for you the first time you click on the Run or Terminal -> Run Task menus. You will be asked if you want to configure and, when you affirm by selecting a configuration, the folder is created and populated. That will happen as long as you have selected one or more plugins (see below). The C#, C++, and Rust plugins supply configurations for debugging. You can then edit them if you wish to modify the way debugging or builds happen. I do all builds in the terminal, so only have a launch.json file, no tasks.json file for building. VS Code settings are stored in three places:
  1. local project settings:
    Debugging settings in launch.json and build settings in tasks.json
    Find in project's .vscode folder, as JSON files launch.json and tasks.json
    Access by opening json file in code editor
  2. user settings:
    Hundreds of settings for Terminal, Keyboard mappings, ...
    Find in C:\Users\[userid]\AppData\Roaming\Code\User\settings.json
    Access: View -> Command Pallet -> Preferences -> Open Settings(JSON)
  3. default settings:
    All available settings (most of which you don't want to change)
    Doesn't appear to be a physical json file.
    Access: View -> Command Pallet -> Preferences -> Open Default Settings(JSON)
You can get to forms for changing preferences from Manage icon (gear) at left bottom of IDE.
Setup for Editing, Building, and Debugging Code: VS Code, as delivered has a very good code editor, but does not have the ability to build, execute, and debug code for the languages of interest to us here. You get those by adding plugins from the plugin selector on the left. Figure 2. VS Code Plugins If you click on the plugins icon on the left border of the IDE you will see something like the view shown in Figure 2. That shows that I have installed plugins for C++, C#, CMake, and Rust. The C++ plugin provides intellisense for the code view and for building and debugging. The plugin uses MsBuild, but the path to that needs to be configured, and you can't easily configure the terminal to use MsBuild if it isn't on your path. For that, CMake is an excellent alternative. You may wish to look at my CMakeDemo repository for a use example. You build the project target by running CMake in the attached terminal. Then run or debug using the Run menu at the top of the IDE. The C# plugin provides intellisense. You need to build your project target in the attached terminal by issuing a "dotnet build" command. Then you can run or debug using the Run menu. The Rust plugin provides intellisense and the ability to build and run the resulting executable from the Run menu. Usually I do all the building in the terminal window and run from there as well. I just use the VS Code run menu to start Rust debugging. Debugging: Figure 3. VS Code Debugging Debugging Rust in VS Code (pdf) One final remark: you get finer control over the debugging process by selecting the debug option on the left border of the IDE, just above the plugin selector. That allows you to select one of multiple debug configurations if you have them defined in launch.json (you find that inside the .vscode folder). You also can view local variables, set watches, and look at machine registers. If you expand Figure 3. by clicking on the image body, you will see the debug control bar at the top which provides controls for single stepping, step-into, step-outof, restart, and quit. The first button on the control bar is a continue button that will move to the next available breakpoint. You set those by clicking in the left margin of the edit window, just to the left of the line numbers. Platforms: All of the above works almost identically on both Windows and Linux. I've used VS Code on macOS, but haven't yet done much development there, but expect that all of these observations carry over to that platform as well. Complementing all of this with a github account makes it easy to move code between platforms, and use virtually the same development processes on each.

3. Development Process:

Topic Rust
Installation Rust: cargo, rustc, clippy
Download Rust.
That includes rustc - the rust compiler, cargo - a package manager, and other tools like clippy. This works for Windows and Linux.
Install Rust pluggin, RLS, from the pluggin dropdown in VSCode's left menu bar. That supports intellisence and debugging. If you have any problems with that, this tutorial may help: VSCode with Rust.
Work Flow
BuildOn-2.pdf
page 6 		Creating Projects:
In VS Code, open the parent folder where you want to create a new Rust project. In the terminal issue the command:
cargo new TestPkg --name test_pkg
That creates a new directory TestPkg with a cargo.toml metadata file and /src folder with hello world Rust code in main.rs. Rust uses the naming conventions:
  1. snake_case:
    Rust wants project names, test_pkg, and data names, my_data, to be snake_case, e.g., all lower case, words separated with an underscore.
  2. CamelCase:
    Rust wants type names Vec<String>, MyPoint, ... to be CamelCase, e.g. each word in a name is capitalized with all the other characters lower case.
That's why the new command ends with --name test_pkg. If you don't use a snake_case name you will repeatedly get warnings about naming formats.
Now you can open the new folder from the File menu and run or start debugging. when you don't need to debug just issue the command:
cargo run test_pkg
in the terminal.
You create a library with the terminal command:
cargo new TestLib --lib --name test_lib
cargo builds the library starter code with test fixtures for unit tests. Once you have some library code and corresponding tests, you run tests with the terminal command:
cargo test
If you manually create an /examples folder as a sibling to the /src folder, you can put demonstration code that uses the library and displays results on the termianl. To do that use the command:
cargo run --example test1
where test1.rs is the demonstration code inside /examples. Two things to note here:
  1. The directory name is examples (plural) but the option is --example (singular).
  2. The file name is test1.rs but the option value is test1 (no extension).
Building Applications Figure 4. Application Structure When you build applications, you will probably factor them into several libraries and an executive. Figure 4. presents an example.
Each library has:
  1. A library directory containing a cargo.toml file, a src directory containing library code, and an examples directory containing one or more test and demonstration files, each with a main function.
  2. Cargo.toml file contains metadata about the library and a list of dependencies, if any. That dependency list helps cargo automatically bind dependencies to the library.
  3. lib.rs file that contains source code for the library and usually a set of configured tests checking that the library maintains its design invariants.
    You run those tests with the command:
    cargo test
    Run from the terminal in the library project directory (where the cargo.toml file resides).
  4. One or more test and demonstration files, each with a main function, test1.rs, ... These files bind to the library and provide visual evidence that library's operations are as expected. You run demonstration tests with the command:
    cargo run --example test1
The Application has an Executive directory with:
  1. A cargo.toml file listing the dependencies of the executive on Lib #1 and Lib #2.
    [dependencies]
    lib1_name = { Path = "../Lib1" }
    lib2_name = { Path = "../Lib2" }
  2. An executive file with a main function and, at the top:
    use lib1_name::*;
    use lib2_name::*;
    This gives executive code access to all the public facilities in both libraries.
The Cargo book has examples of this with several additional options.

4. Epilogue

The following pages provide discussions and code examples for most of the important Rust features.
  Next Prev Pages Sections About Keys