Present is the following build system for SASS files.
{
"cmd": ["sass", "--update", "$file:${file_path}/${file_base_name}.css", "--stop-on-error", "--no-cache", "--style", "compressed"],
"selector": "source.sass, source.scss",
"line_regex": "Line ([0-9]+):",
"osx":
{
"path": "/usr/local/bin:$PATH"
},
"windows":
{
"shell": "true"
},
"working_dir": "$file_path",
}
This script works perfectly for .scss files and, when a .scss file is open, it is automatically selected and Cmd+B builds the source. But this is not the case for .sass files. There, Build is greyed out until the build system is selected manually. What can be done do fix this behaviour?
Make sure you check the scope of the file is the same as your selector. ctrl+shift+alt+p in Windows and Linux and cmd+alt+p in OS X.
Related
I am trying to debug a Rust program in VS Code, but I get an error:
After clicking OK, VS Code opens "settings.json":
I have these extensions installed:
My program is a simple "hello world" app.
Unfortunately VS Code can't debug Rust out of the box :( But no need to worry, just few steps of configuration will do the work :)
Steps
Install C/C++ extension if you are on windows and CodeLLDB if on OS X/Linux
Click Debug -> Add Configuration, a launch.json file should open, you need to change the program name here manually
{
"version": "0.2.0",
"configurations": [
{
"name": "(Windows) Launch",
"type": "cppvsdbg",
"request": "launch",
"program": "${workspaceRoot}/target/debug/foo.exe",
"args": [],
"stopAtEntry": false,
"cwd": "${workspaceRoot}",
"environment": [],
"externalConsole": true
},
{
"name": "(OSX) Launch",
"type": "lldb",
"request": "launch",
"program": "${workspaceRoot}/target/debug/foo",
"args": [],
"cwd": "${workspaceRoot}",
}
]
}
Make sure Allow setting breakpoints in any file is checkend under File -> Preferences -> Settings
For detailed steps and more you can refer the article I used to answer this
Credits- Forrest Smith
From your screenshots, you're on Windows, so here's how to proceed. This assumes you already took care of the basics:
VsCode has the recommended rust-analyzer extension installed.
Your project folder was initialized with cargo init. (Your project's folder name must be the same as the name of your package in Cargo.toml.)
You can cargo run from within your project directory and it works.
As indicated by various locations on the 'Net, you need to install another VsCode extension to make it so you can debug. Since you're on Windows, you want to use the MS C++ DevTools extension for VsCode, instead of the CodeLLDB one.
Next, you need a "launch" configuration setup. Select VsCode's Run >>> Add Configuration... menu item. Choose the C/C++: (Windows) launch option in the drop-down. You'll now have a launch.json file with a single configuration object.
You'll need to change the program property to "${workspaceFolder}/target/debug/${workspaceFolderBasename}.exe"; this depends on your package name being the same as the project folder's name. (I also changed the cwd property to "${workspaceFolder}", though I'm not sure it matters.) To be clearer, here's the configuration I have presently in my launch.json file (the preLaunchTask property is for later):
{
"name": "(Windows) Launch",
"type": "cppvsdbg",
"request": "launch",
"program": "${workspaceFolder}/target/debug/${workspaceFolderBasename}.exe",
"preLaunchTask": "rust: cargo build",
"args": [],
"stopAtEntry": false,
"cwd": "${workspaceFolder}",
"environment": [],
"console": "externalTerminal"
}
At this point, as long as you've already built your project at least once, you can hit F5 and debug.
If you want F5 to also save your changes and rebuild your project before debugging, then you also have to add a build task and configure it to run before debugging starts.
To do that, add the build task by opening the Show All Commands box (either F1 or Ctrl+Shift+p) and choosing Tasks: Configure Task. Select rust: cargo build. It'll create a tasks.json file next to your launch.json; the defaults are all you need. My file looks like this:
{
"version": "2.0.0",
"tasks": [
{
"type": "cargo",
"command": "build",
"problemMatcher": [
"$rustc"
],
"group": "build",
"label": "rust: cargo build"
}
]
}
Then, to hook everything up, you just need to manually add the preLaunchTask property to your launch configuration with a value equal to the label in your task. E.g. "preLaunchTask": "rust: cargo build",, like what I have in my example launch.json up above.
At this point, whenever you press F5, VsCode will save your work, rebuild your project, then start debugging it.
Visual Studio Code is a general editor, but it can be configured to debug rust code.
Step 1.
Assuming that Visual Code, rust and cargo are installed, the first step is to enable the required extensions:
rust-analyzer
CodeLLDB
These only need to be installed one.
Step 2
The second step is to create the rust code. I have a folder called Rust, in which I keep the rust code. Changing to that folder, I use cargo new hello_world to create a new rust project.
Step 3
The third step is to change the folder for the project. There are two plausible options, but only one of them will work.
I changed to my Rust folder, and then I can edit the source code by following ``hello_world - src`.
To debug the code, it is necessary to create a launch.json file, using Run - Add configuration... However, the file isn't correct, with <your program> where the correct name should be. This is the wrong approach.
{
// 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": [
{
"type": "lldb",
"request": "launch",
"name": "Debug",
"program": "${workspaceFolder}/<your program>",
"args": [],
"cwd": "${workspaceFolder}"
}
]
}
The documentation is a bid thin at this point. The correct approach is to pick a different folder, the top level of the project hello_world. The Cargo.toml file is available.
Now, when Run - Add configuration... is used, and the option of LLDB is selected -
the Cargo.toml file can be picked up -
and then the Cargo.toml file is used to correctly build the launch.json file -
{
// 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": [
{
"type": "lldb",
"request": "launch",
"name": "Debug executable 'hello_world'",
"cargo": {
"args": [
"build",
"--bin=hello_world",
"--package=hello_world"
],
"filter": {
"name": "hello_world",
"kind": "bin"
}
},
"args": [],
"cwd": "${workspaceFolder}"
},
{
"type": "lldb",
"request": "launch",
"name": "Debug unit tests in executable 'hello_world'",
"cargo": {
"args": [
"test",
"--no-run",
"--bin=hello_world",
"--package=hello_world"
],
"filter": {
"name": "hello_world",
"kind": "bin"
}
},
"args": [],
"cwd": "${workspaceFolder}"
}
]
}
Now, both Run - Start debugging and Run - Run without Debugging both work properly.
I recently have been using GDB to debug a C++ program. For standard usage, I usually do:
$ cd compiledir
$ compilescript
$ gdb compiled.out
$ run inputfile
compilescript is a program that compiles the code for the particular software I am working on, and only works in compiledir. It reads an external file for compiler flags. For gdb, I include the neccisary -g flag. This works for me to debug via the text interface. However, this text interface is becoming increasingly frustrating to use compared to a IDE, and I know that Visual Studio uses gdb as a backend to debug C++ files by default.
To get started, I let visual studio generate default C++ debugging configurations and tried to change the commands, but I have no idea what it's doing, and there doesn't appear to be much documentation on making custom build/debug configurations, particularly for for the linux version of VScode.
Currently I have:
launch.json (default)
{
// 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": "g++ - Build and debug active file",
"type": "cppdbg",
"request": "launch",
"program": "${fileDirname}/${fileBasenameNoExtension}",
"args": [],
"stopAtEntry": false,
"cwd": "${fileDirname}",
"environment": [],
"externalConsole": false,
"MIMode": "gdb",
"setupCommands": [
{
"description": "Enable pretty-printing for gdb",
"text": "-enable-pretty-printing",
"ignoreFailures": true
}
],
"preLaunchTask": "C/C++: g++ build active file",
"miDebuggerPath": "/usr/bin/gdb"
}
]
}
tasks.json
{
"tasks": [
{
"type": "cppbuild",
"label": "Custom Build",
"command": "compilescript" ,
"options": {
"cwd": "compiledir"
},
"problemMatcher": [
"$gcc"
],
"group": {
"kind": "build",
"isDefault": true
},
"detail": "compile using the custom build script."
}
],
"version": "2.0.0"
}
Running this task, and running it indirectly through the launch.json file both fail. I get the following:
> Executing task: Custom Build<
Starting build...
and it hangs there. I tried to put echo into the build command to see if it was even running, or have it create a file. However, it's like nothing is being run at all and I can't see any printing or files being created anywhere.
What is the proper way to create a custom GDB build/debug task for Visual Studio (Linux Edition)?
Update
I've edited both tasks.json and launch.json, and am able to compile successfully and run GDB with the inputfile I want. However, the environment variables are not configuring properly. I need environment variables to be configured to properly run the inputfile. I currently have:
launch.json
{
"version": "0.2.0",
"configurations": [
{
"name": "g++ - Build and debug active file",
"type": "cppdbg",
"request": "launch",
"program": compiled.out,
"args": [],
"stopAtEntry": false,
"cwd": "${fileDirname}",
"environment": [{"VAR1": "VAR1_VALUE", "VAR2": "VAR2_VALUE"}],
"externalConsole": false,
"MIMode": "gdb",
"setupCommands": [
{
"description": "Enable pretty-printing for gdb",
"text": "-enable-pretty-printing",
"ignoreFailures": true
}
],
"preLaunchTask": "C/C++: g++ build active file",
"miDebuggerPath": "/usr/bin/gdb"
}
]
}
However, when I run the build/debug task, it builds, but doesn't debug, and GDB complains of an error. It appears the "environment" variable is setting something, but I get the following error:
Unable to start debugging. Unexpected GDB output from command "-interpreter-exec console "set env"". Argument required (environment variable and value).
This is how you can set up debugging in C++ without using any Task extensions. Only the launch.json file will be needed.
First, compile your program with the debug flag: -g, and keep it anywhere in your folder.
For example in your active folder (or workspace folder which you have currently opened), Let's say only your source code is present
Program.cpp
# Other files...
Compile your program using the -g flag and create an executable as shown:
gcc -g Program.cpp -o a.out
If your compilation is successful, the executable a.out will be created in the folder, and your root folder will look like
a.out
Program.cpp
# Other files...
Next, you need to create your launch.json file. Since you are not using any Tasks extensions, you can choose the default configuration which will create the said file with most properties filled with their default values.
Now edit the program path in the launch.json to the path of this executable. I've also seen that there's a bug for some Linux OSes for VS Code's C++ debugger that does not work with the internal console. So you might also need to set the "external console" option as true
in this case, you'll make two edits in your launch.json file as
"configurations": [
{
#.... Other stuff
"program": "${fileDirname}/a.out",
#.... Other stuff
"externalConsole": true,
#.... Other stuff
}
]
}
That's all you need. Set breakpoints in your program, and start debugging using the button in the Debug Panel. An external console window will pop up running your program, and the breakpoints should be working.
Also if you're new to debugging in general, remember that every time you change your source code (Program.cpp in this case), you will need to compile and build your debuggable executable again. If you do not do so, your debugging would be glitchy.
Edit:
I see you want to add environment variables. I have a hunch on what you're doing wrong.
It seems to me that you want to set two variables such that
VAR1 = VAR1_VALUE
VAR2 = VAR2_VALUE
Your syntax for this in your launch.json file is incorrect. It should be as shown:
#... Other stuff
"cwd": "${fileDirname}",
"environment":
[
{
"name": "VAR1", "value": "VAR1_VALUE"
},
{
"name": "VAR2", "value": "VAR2_VALUE"
}
],
"externalConsole": false,
#... Other stuff
I have an existing C++ project that I've configured and built in Visual Studio. This project's only target is Windows, no other platforms. I'm using Bash in WSL to launch the executable.
I prefer to develop in Visual Code (not Visual Studio). I prefer to build and launch applications through Bash (strong Linux background).
Right now, my development workflow is:
Edit code in VS Code
Switch to Visual studio and click the build button
Switch to Bash and execute the built program
Since I only keep Visual Studio open for building, I would much prefer to build by command line through Bash.
My naive approach was to use an open source tool to convert the Visual Studio project file into a CMake file. Then cmake & make from Bash, but I stopped when I started encountering errors looking for windows.h (maybe I just need to add some windows include paths to my include_path).
I'm not sure what the best way to go about this would be. Any suggestions would be appreciated!
If the project is entirely C++, there should be no reason to leave WSL. Building and launching the application can be easily handled right there!
You can absolutely build by the command line in bash by using
g++ -o <outputfile> <inputfiles>
However, the easiest way to run the program is to create a build configuration in Visual Code. You will need 2 files: launch.json and tasks.json
To create the launch file, hit F1 (or open your command pallet) and select Tasks: Configure Default Build Task. It should look something like this.
{
"version": "2.0.0",
"tasks": [
{
"type": "shell",
"label": "g++ build active file",
"command": "/usr/bin/g++",
"args": [
"-g",
"${file}", //input files
"-o",
"${fileDirname}/a.out" //output file
],
"options": {
"cwd": "/usr/bin"
},
"problemMatcher": [
"$gcc"
],
"group": {
"kind": "build",
"isDefault": true
}
}
]
}
To create launch.json, go to the 'debug' tab and select 'create a launch.json file'. It should look something like this
{
// 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": "g++ build and debug active file",
"type": "cppdbg",
"request": "launch",
"program": "${fileDirname}/a.out", //output file
"args": [],
"stopAtEntry": false,
"cwd": "${workspaceFolder}",
"environment": [],
"externalConsole": false,
"MIMode": "gdb",
"setupCommands": [
{
"description": "Enable pretty-printing for gdb",
"text": "-enable-pretty-printing",
"ignoreFailures": true
}
],
"preLaunchTask": "g++ build active file",
"miDebuggerPath": "/usr/bin/gdb"
}
]
}
with both of these files in place, all you have to do is hit the run button like in Visual Studio.
MSBuild.exe is provided with my installation of Microsoft Visual Studio. From within WSL bash, I can invoke MSBuild.exe and give the .sln file of my project as the first and only argument.
The compilation output is written to the terminal.
I am compiling scss to css with node-sass.
This works if I just manually type this in the terminal command line:
This works
node-sass --output-style compressed resources/assets/sass/sourcefile.scss public/css/endfile.css
But when I put the options in a Visual Studio Code task it doesn't work anymore. I supply the same arguments so I don't see why it wouldn't work...
VS Code Task doesn't work
{
"version": "0.1.0",
"command": "node-sass",
"isShellCommand": true,
"args": ["--output-style compressed","resources/assets/sass/materialize.scss","public/css/hrmaterialize.css"]
}
You need to separate --output-style and compressed
{
"version": "0.1.0",
"command": "node-sass",
"isShellCommand": true,
"args": ["--output-style", "compressed","resources/assets/sass/materialize.scss","public/css/hrmaterialize.css"]
}
For example, there is package for less LessToCss. As for Sass(or SCSS) I don't know what i should do. Ruby and sublime package Sass are installed.
You have to alter the PATH variable at the end of PATH string in the Environment Variables: Desktop - Properties - Environment Variables. It for win vista/7 users. Detail for 2000/XP here Sass compiler not working in sublime text 3
One way is to download a SASS build compiler from here: SASS Compiler
This is automatic Sublime package that simply builds your file at the place.
However since they released the new version, there seem to be multiple settings on this package - you could try to mess with that a bit and see what it can do nowdays.
Second way is to write your own Build command in Sublime. You do this by going to "Tools>Build System>New Build System..."
{
"cmd": ["sass", "--update", "$file:${project_path}/Project/Web/css/${file_base_name}.css", "--stop-on-error", "--style", "compressed", "--no-cache", "--sourcemap=none"],
"selector": "source.sass, source.scss",
"line_regex": "Line ([0-9]+):",
"osx":
{
"path": "/usr/local/bin:$PATH"
},
"windows":
{
"shell": "true"
}
}
Explanation: I use a folder structure as the following: Project/Web/CSS - If you have the Sublime Project FILE at the same level as Project FOLDER, then this will automatically build your Sass file (placed ANYWHERE in the project file) in your Web/CSS folder. Of course you can change this as you see fitting.
here is 100% solution, as i also using. Actually i am using in mac so, i am not sure about windows because i wouldn't try yet in windows but i think it will works in window's too.
so here is the build;
copy this from starting brackets and paste it into build and then save with any name like (Build to CSS),"
{
"cmd": ["sass", "--update", "$file:${file_path}/../css/${file_base_name}.css", "--stop-on-error", "--no-cache"],
"osx":
{
"path": "/user/local/bin:$PATH"
},
"windows":
{
"shell": true
}
}
If it's working then please comment.
Thanks