I'm trying to edit my launch settings for a CMake project in Visual Studio, but the option is greyed out. I can manually open launch.vs.json file, but the settings there won't behave.
Probably the greying out and the fact that the settings won't behave are linked.
I am running the x64-Debug configuration.
This is how launch.vs.json looks like for me:
{
"version": "0.2.1",
"defaults": {},
"configurations": [
{
"type": "default",
"project": "CMakeLists.txt",
"name": "CMakeLists.txt",
"args": [
"first-argument"
],
"currentDir": "C:\\repos\\myproject"
}
]
}
Since the type of the configuration is "default", I would assume it applies for any configuration that isn't configured. But it doesn't because my "first-argument" is not read.
int main(int argc, char* argv[])
{
if (argc>1)
{
cout << argv[1];
exit(EXIT_SUCCESS);
}
else
{
exit(EXIT_FAILURE);
}
}
The above yields failure.
How to properly configure the debug parameters and how to ungrey Debug and Launch settings?
The Configure CMake debugging sessions documentation says that
If you don't have a debug target selected, this option is grayed out.
Running the x64-debug configuration sounds like the option shouldn't be greyed out, but it still is because you're debugging the Current Document as a target, which Visual Studio doesn't consider a real target. This means that Current Document is neither a Debug, nor a Release target, so the option is greyed out, even if you run it with the configuration named x64-Debug.
Real targets have a drop down menu on the right, usually with a single item mentioning the type of the selected target.
This means you need to select a real target, which should be something like myproject.exe for you.
According to the launch.vs.json schema reference (C++) documentation page, "type": "default" refers to whether the project is a library or an executable, and default just means that it's an executable. It has nothing to it being the default configuration.
The relevant setting to link debug configurations to targets is projectTarget, which is not set in your case. It could be that it used to be that the default would make this configuration available for all targets, including the virtual Current Document, but this would have been an undocumented feature that was unexpectedly deprecated without notice in a new Visual Studio release. This could explain, why it used to work, but it doesn't anymore.
According to the launch.vs.json schema:
projectTarget must exist already and match the name in the Debug Target dropdown.
The easiest way to create a real launch and debug configuration is to
delete your launch configuration,
select a real target, such as "myproject.exe", and make sure it says Debug on the drop-down menu on the right.
Go to Debug -> Debug and Launch settings for myproject.exe, which should open launch.vs.json with a valid configuration, now fill in the "args" parameter as you wish.
Your final configuration should probably look like similar to this:
{
"version": "0.2.1",
"defaults": {},
"configurations": [
{
"type": "default",
"project": "CMakeLists.txt",
"projectTarget": "myproject.exe (myproject\\myproject.exe)",
"name": "myproject.exe (myproject\\myproject.exe)",
"args": [
"first-argument"
],
"currentDir": "C:\\repos\\myproject"
}
]
}
I hope this will serve me as a good reminder to spend more time on documentations and less time messing around.
The answer for me was that somehow the "Startup Item" magically got deselected, so there was no context for Debug and Launch Settings.
In Solution Explorer, right-click on the executable that is the target of the Debug Launch -- "myproject (executable)" in this case -- and select Set as Startup Item.
Now, whenever this executable is selected in the Solution Explorer, the option "Debug and Launch Settings for myproject" appear in the Debug dropdown menu.
Related
I'm trying to use a modified version of imgui through vcpkg.
I've created a git repository to be used for the registry (https://github.com/altschuler/vcpkg-custom-ports), and copied over the imgui port configuration, and made the changes I needed (following guides like this and this).
However, vcpkg seems to ignore the entry for the custom repo in vcpkg-configuration.json, it simply doesn't load anything from it (I know because I tried changing the repository url to something that doesn't exist). If I set the default-repository to my custom one it does load stuff, but then all the packages I want from the builtin registry obviously fail to install.
Note: the reason I need a custom port for imgui is that I need to compile some definitions (basically just do target_compile_definitions in its CMakeLists). If you know of an easier way to do that I'm all ears.
vcpkg-configuration.json:
{
"registries": [
{
"kind": "git",
"baseline": "e3b33f3a548f20ba06b2959aa3701bd50ece0638",
"repository": "https://github.com/altschuler/vcpkg-custom-ports.git",
"packages": ["imgui"]
}
]
}
vcpkg.json:
{
"name": "tester",
"version-string": "0.1.0",
"dependencies": [
"lager",
"sdl2",
{
"name": "imgui",
"features": ["docking-experimental", "sdl2-binding", "opengl3-binding"]
},
"immer",
"cereal",
"rxcpp",
"range-v3",
"glew",
"boost"
]
}
Try setting an environment variable
VCPKG_FEATURE_FLAGS=manifests,binarycaching,registries
AFAIK, some features are not enabled by default. Seems that manifests are automatically enabled, so vcpkg.json gets picked up, but perhaps "registries" are not enabled by default. (Disregard "binarycaching", if you don't use it).
This is what is working for me.
When I woke up this morning and launched VSCode my default terminal on launch, and when running tasks is now powershell, instead of Git Bash. I am on windows. I have tried changing the settings.json to no avail. Is there something I'm missing?
{
"workbench.startupEditor": "newUntitledFile",
"terminal.integrated.shell.windows": "C:\\Program Files\\Git\\bin\\bash.exe",
"[javascript]": {
"editor.defaultFormatter": "rvest.vs-code-prettier-eslint"
},
"aws.samcli.location": "C:\\Users\\king\\AppData\\Roaming\\npm\\sam.exe",
"typescript.updateImportsOnFileMove.enabled": "always",
"[html]": {
"editor.defaultFormatter": "vscode.html-language-features"
},
"editor.formatOnSave": true,
"editor.formatOnPaste": true,
"javascript.updateImportsOnFileMove.enabled": "always",
"explorer.confirmDragAndDrop": false,
"diffEditor.maxComputationTime": 0,
"extensions.ignoreRecommendations": true,
"[typescript]": {
"editor.defaultFormatter": "esbenp.prettier-vscode"
},
"editor.renderControlCharacters": true,
"[jsonc]": {
"editor.quickSuggestions": {
"strings": true
},
"editor.suggest.insertMode": "replace"
},
"window.zoomLevel": 0,
"editor.accessibilitySupport": "off",
"workbench.editor.untitled.hint": "hidden",
"terminal.integrated.defaultProfile.windows": "Git Bash",
"terminal.external.windowsExec": "C:\\Program Files\\Git\\bin\\bash.exe",
"terminal.explorerKind": "external",
"terminal.integrated.automationShell.linux": ""
}
I found this related SO post making the default powershell, but I didn't see anything that was incorrect about my setting...especially because my goal is the opposite- to stop Powershell!
Update: Version v1.60.0 had a bug. Upgrade to v1.60.1 or higher for a fix.
The bug manifested in the following symptoms:
The Open in Integrated Terminal shortcut-menu command in the Explorer pane's shortcut always uses the built-in default shell (PowerShell on Windows), ignoring the configured one.
The same goes for running tasks (with or without a separate terminal.integrated.automationShell.* setting).
Also, if a given folder or workspace happened to have an integrated terminal open when quitting Visual Studio Code, the shell that is launched when the integrated terminal automatically reopens the next time is again the built-in default shell, not the configured one. By contrast, if reopening doesn't auto-open the integrated terminal, opening it manually does respect the configured default shell, and so does manually creating another shell instance later.
See GitHub issue #132150
The following information turned out to be unrelated to the bug, but is hopefully still useful general information about Visual Studio Code's recent change in how shells for the integrated terminal are configured:
Migrating from the legacy default shell settings to shell profiles:
Recently, the "terminal.integrated.shell.*" and "terminal.integrated.shellArgs.*" settings were deprecated and replaced with a more flexible model that allows defining multiple shells to select from, via so-called shell profiles, optionally defined in setting "terminal.integrated.profiles.*", with an associated mandatory "terminal.integrated.defaultProfile.*" setting referencing the name of the profile to use by default - which may be an explicitly defined custom profile or one of the built-in, platform-appropriate default profiles.
Note: * in the setting names above represents the appropriate platform identifier, namely windows, linux, or osx (macOS).
As of v1.60.1, if legacy "terminal.integrated.shell.*" settings are also present, the new settings take precedence (even though the tooltip when editing "terminal.integrated.shell.*" in settings.json suggests that this change is yet to come).
In the absence of both settings, Visual Studio Code's built-in default shell is used, which on Windows is PowerShell,[1] and on Unix-like platforms the user's default shell, as specified in the SHELL environment variable.
Recent Visual Studio Code versions, starting before v1.60 - seemingly as one-time opportunity - displayed a prompt offering to migrate the deprecated settings to the new ones.
Accepting the migration results in the following:
Creation of setting "terminal.integrated.shell.*" containing a custom shell profile derived from the values of legacy settings "terminal.integrated.shell.*" and, if present, "terminal.integrated.shellArgs.*"; that custom profile's name has the suffix (migrated)
Creation of setting terminal.integrated.defaultProfile.* whose value is the migrated profile's name, making it the default shell.
Removal of legacy settings "terminal.integrated.shell.*" and "terminal.integrated.shellArgs.*"
If you decline the migration, you can later effectively perform it by re-choosing the default shell, as described below.
Note: The new "terminal.integrated.defaultProfile.*" setting that is created in the process then effectively overrides the legacy "terminal.integrated.shell.*" and "terminal.integrated.shellArgs.*" settings, but the latter won't be removed automatically. To avoid confusion, it's best to remove them from settings.json manually.
Choose the default shell profile to use in order to (re)specify the default shell:
Click on the down-arrow part of the shell-selector icon () on the right side of the integrated terminal, select Select Default Profile, which presents a list of the defined profiles to select the default from - in the absence of explicitly defined profiles, standard profiles are offered (see below).
This translates into a terminal.integrated.defaultProfile.* setting in settings.json, whose value is the name of the chosen shell profile - which may be the name of a built-in profile or one of the ones explicitly defined in "terminal.integrated.profiles.*"
Note: This shell is by default also used for tasks (defined in tasks.json), but that can be overridden with a "terminal.integrated.automationShell.*" setting pointing to the executable of an alternative shell.
Optionally, in your settings.json file, you may create a platform-appropriate terminal.integrated.profiles.* setting with shell profiles of interest:
Note: Even if your settings.json contains no (platform-appropriate) "terminal.integrated.profiles.*" setting, Visual Studio code has built-in standard profiles it knows of and offers them for selection when choosing the default shell.
These standard profiles are a mix of shells that come with the host platform as well as some that Visual Studio detects dynamically on a given system, such as Git Bash on Windows.
To create the standard profiles explicitly, do the following:
Note: You may choose to do this in order to customize the standard profiles. However, if your intent is merely to add custom profiles - see this answer for an example - it isn't necessary to create the standard profiles inside the "terminal.integrated.profiles.*" setting, because Visual Studio Code knows about them even if not explicitly defined.
Via File > Preferences > Settings (Ctrl-,), search for profiles and click on Edit in settings.json below the platform-appropriate Terminal > Integrated > Profiles > * setting; this will open settings.json for editing, with the standard profiles added; simply saving the file is sufficient.
Note: If the "terminal.integrated.profiles.*" setting shown doesn't contain the expected, platform-appropriate standard profiles, a setting by that name may already be present; to force creation of the standard profiles, remove or comment out the existing setting and save the file, then try again.
On Windows, you'll end up with something like the following:
"terminal.integrated.profiles.windows": {
"PowerShell": {
"source": "PowerShell",
"icon": "terminal-powershell"
},
"Command Prompt": {
"path": [
"${env:windir}\\Sysnative\\cmd.exe",
"${env:windir}\\System32\\cmd.exe"
],
"args": [],
"icon": "terminal-cmd"
},
"Git Bash": {
"source": "Git Bash"
}
}
The answer you link to in your question, which provides an overview of the various types of shells used in Visual Studio Code, has been updated to reflect the information about the new shell profiles.
[1] Note: If a PowerShell (Core) v6+ installation is found, it takes precedence over the built-in Windows PowerShell version.
Edit:1
Note: Now this bug has been fixed by VSCode. Just update your VSCode to the latest version. (17-Sep-2021)
I have a temporary solution.
First paste this code in settings.json and save
"terminal.integrated.defaultProfile.windows": "Git Bash",
"terminal.integrated.profiles.windows": {
"C:\\Program Files\\Git\\bin\\bash.exe": {
"path": "",
"args": []
}
},
Before closing VSCode select Output instead of Terminal
Now you can open VSCode
After VSCode is loaded, you need to click on Terminal. After this you will now see bash.
Select output before whenever you close VSCode.
Reference: VSCode is suddenly defaulting to PowerShell for integrated terminal instead of $Bash in Windows
Note: This is not an solution. I shared this because maybe it can save you from getting disappointed.
This is my first post, if there is any mistake please let me know so that I can correct it.
You can always download and install previous releases from the official website https://code.visualstudio.com/updates/v1_59 (currently at the top).
As version 1.60 was bugged, v1.59 is a good candidate.
Disable automatic updates
Explained here.
Open User Settings File > Preferences > Settings.
Add "update.mode": "none" to your settings.
Install older version
Afterwards you can just overwrite current version with the installation of downloaded version.
Note: Wait for next version to fix it, so remember you had automatic update disabled!
I have same problem but I try run command prompt. I fix it by adding to ...\Code\User\settings.json
"terminal.integrated.automationShell.windows": "cmd.exe",
This could be related to issue 138999 which will add a mitigation/enhancement to VSCode 1.70 (July 2022) with PR 154290 and commit 91b82c0
increase barrier for available profiles to be ready
Wait up to 20 seconds for profiles to be ready so it's assured that we know the actual default terminal before launching the first terminal.
This isn't expected to ever take this long.
For VSCode with synchronized user settings, the profile might take more time than expected to fully load, hence the advantage of that workaround.
Simply replaced the CMD by Git Bash :-) in the settings.json
"terminal.integrated.profiles.windows": {
"PowerShell": {
"source": "PowerShell",
"icon": "terminal-powershell"
},
"Command Prompt": {
"path": [
//"${env:windir}\\Sysnative\\cmd.exe",
//"${env:windir}\\System32\\cmd.exe"
"C:\\PrivateProgramms\\Git\\bin\\bash.exe"
],
"args": [],
"icon": "terminal-cmd"
},
"Git Bash": {
"source": "Git Bash"
//"path": [ "C:\\PrivateProgramms\\Git\\bin\\bash.exe" ],
//"args": [],
//"icon": "terminal-cmd"
}
},
"terminal.integrated.defaultProfile.windows": "Command Prompt"
My goal is to run e.g. MyTarget.exe "C:\Users\MHebes\config.json from MSVC.
I can do this in Debug mode, but can't get it to work in Release.
If I right-click on my top-level CMakeLists.txt, I can see the launch.vs.json for the current open folder:
..\..\..\..\AppData\Local\Microsoft\VisualStudio\16.0_45505961\OpenFolder\launch_schema.json:
{
"version": "0.2.1",
"defaults": {},
"configurations": [
{
"type": "default",
"project": "CMakeLists.txt",
"projectTarget": "MyTarget.exe (apps\\MyTarget\\Debug\\MyTarget.exe)",
"name": "Debug launch target for MyTarget",
"args": [
"C:/Users/MHebes/config.json"
]
}
]
}
I don't fully understand this in the first place, since the launch.vs.json docs don't mention anything about a "configurations" list but this was how it was auto-populated when I added a new configuration. Regardless, this works in debug modeāthe "Debug launch target for MyTarget" option shows up in the Select Startup Item... list when Debug is selected in the dropdown.
I have added a Release/RelWithDebugInfo configuration to my CMakeSettings.json.
But when I actually switch the build to Release, the Select Startup Item... list is only populated with default CMakeTargets.
How do I add command-line launch arguments to Release builds?
My end goal is that when I Start Debugging in Release mode, it will build a Release exe and run it with some args.
I think I figured it out. I added another configuration with a different target:
{
"version": "0.2.1",
"defaults": {},
"configurations": [
{
"type": "default",
"project": "CMakeLists.txt",
"projectTarget": "MyTarget.exe (apps\\MyTarget\\Debug\\MyTarget.exe)",
"name": "Debug launch target for MyTarget",
"args": [
"C:/Users/MHebes/config.json"
]
},
{
"type": "default",
"project": "CMakeLists.txt",
"projectTarget": "MyTarget.exe (apps\\MyTarget\\RelWithDebInfo\\MyTarget.exe)",
"name": "RelWithDebInfo launch target for MyTarget",
"args": [
"C:/Users/MHebes/config.json"
]
}
]
}
The Microsoft Docs page on Configure CMake debugging sessions says:
projectTarget: Specifies the CMake target to invoke when building the project. Visual Studio autopopulates this property if you enter launch.vs.json from the Debug Menu or Targets View. This value must match the name of an existing debug target listed in the Startup Item dropdown.
Since Visual studio populates the Startup list with names that include the path to the executable, and because that path is dependent on the configuration name (i.e. buildRoot in CMakeSettings.json includes ${name} in the path by default), this explains why projectTarget must include the configuration path.
This seems like an insane interface to me. Maybe I'm doing something wrong.
I have simple console application in C++ that I succeed to compile with Visual Studio.
I wanted to try Visual Studio Code so I copied the directory to the computer with Visual Studio Code installed.
I installed the C++ extension:
I put break point at the beginning and press F5 and I received an error:
launch: program 'enter program name, for example
c:\Users\student1\Desktop\ConsoleApp\a.exe' does not exist.
Of course the the program does not exist, I am compiling it in order for the code to become the program.
I followed the instruction and I went to the launch.json file:
I changed the "program" value to: "${workspaceRoot}/a.exe" instead of "enter program name, for example ${workspaceRoot}/a.exe".
But the same problem still exist.
Any idea ?
Spent 2 hours on this.
Ideally, VS Code shouldn't make so difficult for beginners
VS Code can give prompts for each installation, etc. automatically, in a step by step manner, like Idea editors, so that it wont be so long procedure for beginners.
Sequence of steps to do (most of the things are one time):
one time:
install a C/C++ complier, add to PATH environment variable
install C/C++ plugin for visual studio code
tell visual studio code where the compiler is and what is the short cut to build and run
these are files under ".vscode" (see below)
every project:
crate a project
build project
run project
Detailed:
One time:
Note: Point 'A' below can be skipped if you already have a compiler.
A. Install a compiler (if you don't have one already)
Example below, installs MinGW c++ compiler on Windows:
Download from here: https://sourceforge.net/p/mingw-w64/mailman/message/36103143/
1. For windows, I downloaded https://sourceforge.net/projects/mingw-w64/files/mingw-w64/mingw-w64-release/mingw-w64-v5.0.3.zip
2. unzip mingw-w64-v5.0.3.zip
3. rename unzipped folder to MinGW, Move it to C:\MinGW\
4. verify that you have "C:\MinGW\bin\gcc.exe" director/file, otherwise make necessary change to folder
B. Add your compiler to PATH environment variable
1. Add "C:\MinGW\bin" to PATH > user environment variable
2. verify gcc command works from cmd
restart your cmd
run below command in 'cmd'
where gcc
The output should be: C:\MinGW\bin\gcc.exe
C. Restart your visual studio code
1. install C/C++ plugin, as below:
From Menu
View > Extension
Search & Install below extension
C/C++
Every project:
Note: You can copy paste the .vscode folder every time
A. Create a below "myproj" folder & files, like below in below structure:
C:\myproj\myfile.cpp
C:\myproj\.vscode\
C:\myproj\.vscode\c_cpp_properties.json
C:\myproj\.vscode\launch.json
C:\myproj\.vscode\settings.json
C:\myproj\.vscode\tasks.json
B. Download & overwrite the above ((5 files)), from below link
https://github.com/manoharreddyporeddy/my-programming-language-notes/tree/master/vscode-c%2B%2B
C. Restart your visual studio/vs code
D. Open project in vs code & run project:
Drag and drop "myproj" folder into visual studio code
BUILD PROJECT: press "Ctrl + Shift + B" to build your myfile.exe
RUN PROJECT: press "Ctrl + F5" to run your myfile.exe
Thats all, hope that helped.
More info: https://code.visualstudio.com/docs/languages/cpp
Optional
To format C++ better
C++ formatting
1. Install Clang:
Download from: http://releases.llvm.org/download.html#5.0.2
I have downloaded for windows
"Pre-Built Binaries:" > Clang for Windows (64-bit) (LLVM-6.0.0-win64.exe)
2. Select Add to PATH while installing.
3. Install vs code plugin "Clang-Format" by xaver, this wraps above exe.
4. Restart visual studio code.
Note:
Issue: As of June 2018, Clang does not format the newer C++17 syntax correctly.
Solution: If so, move that code to another file/ comment & restart the vs code.
That's all. Now press Alt+Shift+F to format (similar key combination in other OS)
The error ".exe file does not exist" in vscode can occur because of the following reasons:
If the file name contains white spaces
If there is re-declaration of variables or other kind of compilation errors
This problem is mainly due file name , as per below table the name of the binary will be audioMatrixBin in windows folder not audioMatrixBin.exe, but we have to mention filename.exe here.
{
"name": "(Windows) Launch",
"type": "cppvsdbg",
"request": "launch",
"program": "audioMatrixBin.exe",
"args": ["AudioMxrMgr4Subaru.conf"],
"stopAtEntry": false,
"cwd": "${workspaceFolder}",
"environment": [],
"externalConsole": true
}
]
}
Go to launch.json(we've encounter problem with .json file that's why we're here)
Change 'cwd' & 'miDebuggerPath' where your 'gdb' is(mine is default).
"cwd": "C:\\MinGw\\bin",
"miDebuggerPath": "C:\\MinGw\\bin\\gdb.exe"
(you can copy-paste if yours is default too).
Now run with 'gcc.exe-Build and debug active file'
(run your file with this option, this should run)
Make sure your "program" and "cwd" properties are actually correct. Check the path it tells you and compare with the path you want them to be.
BUILD your PROJECT .exe file : press "Ctrl + Shift + B" to build your example.exe
It seems that launch.json file needs to have the correct configs.
please check the configurations as per the below link, if you are using VS build tools
https://code.visualstudio.com/docs/cpp/config-msvc
or delete the launch.json file, gotoRun > Add Configuration... and then choose C++ (Windows), Choose cl.exe build and debug active file. Check the new name in launch.json and try again.
This video explain it very well how to setup vscode for c, I did it on Ubuntu.
https://www.youtube.com/watch?v=9pjBseGfEPU
Then I use this reference to setup c++,
https://code.visualstudio.com/docs/cpp/config-linux
I just had to replace "command": "/usr/bin/gcc" with
"command": "/usr/bin/g++",
from the example on the video.
and you can update the label on both tasks and launch if you want it.
this is how my c++ setup ended up.
tasks.json for c++
{
// See https://go.microsoft.com/fwlink/?LinkId=733558
// for the documentation about the tasks.json format
"version": "2.0.0",
"tasks": [
{
"type": "shell",
"label": "C/C++: g++ build active file",
"command": "/usr/bin/g++",
// "command": for classic c, "command": "/usr/bin/gcc",
"args": [
"-g",
"${file}",
"-o",
"${fileDirname}/bin/${fileBasenameNoExtension}"
],
"options": {
"cwd": "${workspaceFolder}"
},
"problemMatcher": [
"$gcc"
],
"group": {
"isDefault": true,
"kind": "build"
}
}
]
}
launch.json for c++{
// 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": "${fileDirname}/bin/${fileBasenameNoExtension}",
"args": [],
"stopAtEntry": false,
"cwd": "${workspaceFolder}",
"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"
}
]
}
In your launch.json file check the "miDebuggerPath" and see if the same path is defined in your environment variables.
To resolve this proble one has to make sure three things are in order:
You have successfully downloaded and install the gcc (compiler) and gdb (debugger). To check this you should be able to type
gcc --version
and
gdb --version
and get the correct results
Once done with this step compile the myfile.c using this command.Make sure that your file has a main() function ,otherwise the produced myfile.exe will not be recognised by the debugger.
gcc -c myfile.c -o myfile.exe
Add a launch configuration using gcc.
In the launch configuration
manually add the path to the executable "program": "${workspaceFolder}/myfile.exe"
In the launch configuration
manually add the path to the debugger "miDebuggerPath": "C:/MinGW/bin/gdb.exe"
Nuke everything and use the build active file tasks:
Delete all files within the .vscode folder.
Select Terminal > Configure Tasks
Select appropriate system task (i.e. for Mac, C/C++: clang build active file).
Open .vscode/tasks.json
Configure C++ language standard by specifying the std flag (i.e. "-std=c++17") at the top of the args array.
the problem for me was an error during the run time that the compiler didn't notice before. then the .exe file didn't built, therefore the .exe file does not exist so you have to check if your script is fine even if no error is found by the debugger.
{In launch.json file where name : (Gdb) launch ,
step 1: enter the complete address of program for eg, c:/users/.....xyz.exe.
step 2: In Mi-debugger path complete address of bin in mingw folder which contains the Gdb debugger so the address would be c:/mingw/....gdb.exe repeat step 2 for the first configuration in launch.JSON
step 3 IN CWD , copy the same path but only till /bin
That should work }
I've made a custom build in sublime which runs my program and it works fine. But I have the Makefile build as default. Is there a way, to let Ctrl+B use the default build (in my case Makefile) and have another shortcut (Ctrl+Shift+B) use another build. If yes, how?
I tried using this :
[
{ "keys": ["ctrl+shift+b"], "command": "build buildName" }
]
but it isn't working and watching at the sublime documentation this command is only for the default build selected.
Thanks in advance.
The actual syntax of the keybinding should be like so:
{ "keys": ["f1"], "command": "build", "args": {"build_system": "Packages/Python/Python3.sublime-build"} },
I would actually recommend against using CtrlShiftB as your custom keybinding, as it is already applied to the "Build With" command.