Visual Studio Code cannot find the g++ command of my MinGW-w64 - g++

Visual Studio Code cannot find the g++ command of my MinGW(btw, intelliSense has no problem because I have set c_cpp_propertites.json correctly). Any idea? Thanks in advance, the following is the output:
Executing task: g++ -g helloworld.cpp
g++ : The term 'g++' is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again.

What happened to me was that VSC didn't automatically source my PATH. After I added g++, closed and reopened it, the issue was solved.

I'm having a similar issue and I believe I've narrowed it down to being due to "g++" being your command. Check your task config file and note what you have set for "command".
"command" is what the task is going to try and run along with whatever arguments you have stipulated which in your case I assume is "-g" and "helloworld.cpp".
Now, what I'm having trouble determining is why it isn't finding g++ as if I try to compile a source file via a command prompt I have no issue and it compiles successfully.
Looking through the documentation for VS code I did find a way to reference your environment variables in the task config: {env:Path} will serve as prefix for my User environment variable "Path" which has a reference to c:\Mingw\lib\bin (note this is an accurate path, simply an example). I think we're pretty close to getting it to work it's just a matter of pathing to g++. My next attempt I think I will simply change "command" to reference an absolute path to g++.

Step 1 - Copy your path of bin file of your mingw compiler (eg. C:\Program Files\mingw-w64\x86_64-8.1.0-posix-seh-rt_v6-rev0\mingw64\bin)
Step 2 - Go to properties by right clicking 'This PC' button.
Step 3 -
Step 4 -
Step 5 -
Step 6 -
If this not work, try this again from beginning.

The temporary solution for this problem is as follows :---
Open VsCode in Run as administrator .
And set your tasks.json as follows. For ex :-- If your file name is main.cpp
It will build the file without error.

I've just had the same problem. Adding the \mingw\bin folder to my PATH variable didn't help. Running g++ in a cmd or PS window worked without a problem so it seems like VSCode is having problems reading or resolving the PATH variable.
To bypass this problem I've included the complete path to g++.exe in the command property of my task. After saving the task, VSCode was able to build my .cpp file.
{
// See https://go.microsoft.com/fwlink/?LinkId=733558
// for the documentation about the tasks.json format
"version": "2.0.0",
"tasks": [
{
"label": "build g++",
"type": "shell",
"command": "C:\\mingw-w64\\x86_64-8.1.0-posix-seh-rt_v6-rev0\\mingw64\\bin\\g++.exe",
"args": ["-g", "-o", "${fileBasenameNoExtension}", "${fileBasename}"],
"group": {
"kind": "build",
"isDefault": true
}
}
]
}

Search Path in windows search box
click on Environment Variables
Click on Path and hit Edit
Go to C: Drive and look for MinGW folder
then go to bin folder and copy the path
Create a New variable and paste the path and move it to the top
after that hit ok and restart your terminal/vs code to make it work again.

I've fixed this issue by adding the path to the bin of mingw-w64 to the windows path by typing setx path into the windows command prompt.
setx path "%path%;PATHTOBIN"
It would likely return that the PATH has been truncated to 1024 bits, in which case I edited the path variable directly in the register:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Environment

Open your tasks.json and launch.json. Make sure that the "preLaunchTask" in launch.json is set to the same string value as the "label" of one the object in the tasks array in the tasks.json file.
launch.json file
tasks.json file

first, you need to make sure you have added the
C:\MinGW\bin
in the environment variable if you using windows environment

After installing MinGW, restart VS Code. The program will definitely execute.

Well, I also faced this problem and I tried every single method but it didn't work properly. But then I did this and it worked.
In Environmental variables under SYSTEM VARIBALES create a VARIABLE named CLASSPATH and VARIABLE VALUE as <path to MinGW> by clicking NEW in SYSTEM VARIABLES

'$' I had similar problem with vsc.
For me worked out:
1) Making(Remaking) system variable path to C:\MinGW\bin.
2) in c_cpp_properties.json adding:
"browse": {"path": ["${workspaceFolder}","C:\\MinGW\\lib\\gcc\\mingw32\\8.2.0\\include\\c++"]}

Edit the system environment variable ==> Environment variable.. ==>system variable ==>Click Path ( or Select Path + edit) ==> New paste C:\MinGW\bin ==> Ok

add the compiler path in the file c_cpp_properties.json as the following
"compilerPath": "C:/MinGW/bin/g++.exe",
it was working for me(add the path with respect to yout g++ exe from your mingw directory) ..

For me, closing and reopening VS Code without changing anything solved my problems.

Follow instructions given here for the C/C++ programming With VS code
After that if you still get this error that is after instaling MinGW.
Just close the VS code, and open it again.
Everything will fine.

Related

Run code formatter from the command line with PhpStorm open

If I go to my PhpStorm\bin folder I can run the format.bat command to format files from the command line e.g.
phpstorm format -r C:\path\to\my\code -r -s c:\path\to\my\settings.xml
and that works great. However I cannot run the command if PhpStorm is open, I get an error:
Only one instance of PhpStorm can be run at a time
Not ideal to have to close my IDE or have to use a 3rd party code formatter. Is there any workaround? Without installing another copy of PhpStorm.
It's a known issue, please see: https://youtrack.jetbrains.com/issue/IDEA-160462
The link from y.bedrov led me to here https://confluence.jetbrains.com/display/IDEADEV/Command-Line+Source+Code+Formatter with a potential solution.
Unfortunately I don't seem to be able to get it to work, I had to resort to copying my PhpStorm directory and using the copy instead. But I add it here in hopes that it helps others
Running Command-Line Formatter when the IDE is Running
On Linux/MacOS
Go to /bin directory where is a directory where Intellij IDEA or Intellij IDEA-based product is installed.
Copy idea.properties to some other file, for example, format.properties
Modify format.properties as follows:
Uncomment the lines:
# idea.config.path=${user.home}/.IntelliJIdea/config
# idea.system.path=${user.home}/.IntelliJIdea/system
Change them to point to some directories which differ from defaults, for example:
idea.config.path=${user.home}/.IntelliJIdea/format/config
idea.system.path=${user.home}/.IntelliJIdea/format/system
Modify format.sh by adding the line with IDEA_PROPERTIES variable:
\#!/bin/sh
\# ------------------------------------------------------
\# IntelliJ IDEA formatting script.
\# ------------------------------------------------------
IDE_BIN_HOME="${0%/*}"
export IDEA_PROPERTIES=$IDE_BIN_HOME/format.properties
exec "$IDE_BIN_HOME/idea.sh" format "$#"
Run format.sh without closing the IDE, it should give the following output:
IntelliJ IDEA ..., build ... Formatter
Usage: format [-h] [-r|-R] [-s|-settings settingsPath] path1 path2...
-h|-help Show a help message and exit.
-s|-settings A path to Intellij IDEA code style settings .xml file.
-r|-R Scan directories recursively.
-m|-mask A comma-separated list of file masks.
path.. A path to a file or a directory.
On Windows
You have to create a separate format.properties file as described above for Linux/MacOS.
Change format.bat file by adding a line with IDEA_PROPERTIES variable as follows:
#ECHO OFF
::----------------------------------------------------------------------
:: IntelliJ IDEA formatting script.
::----------------------------------------------------------------------
SET IDE_BIN_DIR=%~dp0
SET IDEA_PROPERTIES=%IDE_BIN_DIR%\format.properties
CALL "%IDE_BIN_DIR%\idea.bat" format %*
Run format.bat, it will list the command-line formatter options.
This guide works for me. But ensure use PHPSTORM_PROPERTIES instead of IDEA_PROPERTIES when export environment variable as described in the article:
export IDEA_PROPERTIES=$IDE_BIN_HOME/format.properties
And what's more, from version 2022.1, IntelliJ IDEA supports dry run which is very useful for format validation based pre-commit git hook.

ROS Kinetic 'catkin_make' Fails because PROJECT_NAME is set to Project

I have been using ROS Kinetic for a while, and today when I went to make a new catkin workspace following the ROS tutorials page (http://wiki.ros.org/catkin/Tutorials/create_a_workspace) I get a CMake Error stating that PROJECT_NAME is set to Project, which is invalid. I have never run into this issue with any of my other work spaces I have created.
I do not want to mess with toplevel.cmake out of fear of screwing up my other work spaces.
Any ideas why this is happening?
CMake Error at /opt/ros/kinetic/share/catkin/cmake/catkin_package.cmake:91 (message):
catkin_package() PROJECT_NAME is set to 'Project', which is not a valid
project name. You must call project() before calling catkin_package().
Thank you.
I was able to reproduce the above error you are getting. For that what I did is opened my CMakeLists.txt and commented the second line which defines the package Name, i.e., project(package_name). After that, I tried to build my package via catkin_make, but got below error(see the error inside yellow box):
Then, I tried to build the same package after uncommenting the above line. This time I was able to build my package(test, in my case) successfully, without any error.
CMakeLists.txt file contains project() as well as catkin_package() and the former function should be called before catkin_package() inside the file. So, project(package_name) is either missing from your CMakeLists.txt file or is commented.
If it is missing, then manually add it. If it is there, but commented then uncomment it.
Read more about the correct format of CMakeLists.txt file from here.
ironically, you'll be running : sudo apt-get install ros-<distro_name>-catkin to reinstall catkin because even if u clear your entire workspace the problem will persist due to some symbolic link or something broken in the package which will always result in the same error, upon reinstalling catkin it worked for me, knowing that I had the exact same issue.
Had to come answer this because I think I did the same thing OP did. Here's what happened: There are supposed to be TWO CMakeLists.txt in your project folder. One lives at ProjectName/src and should be read-only and should actually be a link to your /opt/ros/your-ros-distro/share/catkin/cmake/toplevel.cmake folder.
If you do like I did, and I'm assuming like OP did, and edit that file, and then use your superuser to overwrite that file, then you are (1) breaking all of your catkin projects, because ALL of the catkin projects link to this one file, AND you're misconfiguring this project because the CMakeLists.txt file you're supposed to modify actually exists a folder deeper, at ProjectName/src/ProjectName/. THIS is where you're supposed to put the CMakeLists.txt file that names your project, where your package.xml file is supposed to go, etc.
If you use superuser to force-overwrite the read-only CMakeLists.txt file then you're going to have a bad day. Fortunately you can fix that file by fixing the toplevel.cmake folder, which you can do by reinstalling the catkin package: sudo apt-get install --reinstall ros-indigo-catkin
And, to put this in terms of OP's question specifically - the project() needs to get named at the inner file, the ProjectName/src/ProjectName/CMakeLists.txt, because again the root file is read-only and should never be modified.

Error in running trace32 with command line

I have a .cmm file which helps in debugging of Qcomm chipsets.
This file has a line : cd ../../../../../modem_proc
When I run this same cmm file using T32 GUI, it runs fine and does the work. But when I am trying to run the same file using windows command line using,
C:\T32\bin\windows64>t32mqdsp6.exe -c C:\T32\config.t32 -s D:\path\to\xxx.cmm
Following error is thrown in T32: syntax error in B::cd ../../../../../modem_proc
What am I missing here? I have no hands-on experience with T32 what-so-ever.
The problem probably results from different working directories. Type
PRINT OS.PWD()
in the GUI and add it to the top of the script. I'd suspect they are different.
Don't use working directory relative paths, instead use paths relative to the script, e.g.
CD ~~~~/../../../../modem_proc
The four tilde (~) symbols mean "directory of the currently executed script". There's still a possible issue with this solution when using multiple GUIs and the intercom, but for most use-cases this should be OK.
When starting TRACE32 (up to build 99518) without option "-s", it starts a default script t32.cmm form your TRACE32 installation directory. But t32.cmm is not executed, when "-s" is used.
So probably your t32.cmm is changing your working directory. If so you can fix the issue by adding the line
DO ~~/t32.cmm
to the top of your script xxx.cmm.
See also https://www.lauterbach.com/frames.html?help_autostart.html
The default working path is also set by the TRACE32 configuration file. That is the file passed with "-c". So if your are using a different configuration file than C:\T32\config.t32 when starting your TRACE32 GUI the normal way, then you should use that configuration file also when starting TRACE32 from the command line.
To get the path of the configuration file usually used, start TRACE32, execute command AREAand then command PRINT OS.PCF()
Furthermore dev15 is probably right here https://stackoverflow.com/a/53671657/4727717:
Use paths relative to the PRACTICE script (cmm-file) by starting each path with four tildes.

How to fix 'VSTest.Console.exe' is not recognized as internal or external command

i am trying to run my MSTest from the command line, and I cannot for the life of me figure out why this isn't working. Yes it works if I manually change the directory to the executable, but I don't want to do that every time.
In the image below, you can see I have set up the environment variable, and yes I have restarted my computer many times.
You need to add it to your PATH variable. In that same dialog edit the Path variable and add the folder to the path. For example, I have enterprise installed, so I used this path:
C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Common7\IDE\CommonExtensions\Microsoft\TestWindow
After updating the path you will need to close and restart the cmd window.

LiteIDE won't run code after building, Process failed to start

About a week ago I installed golang successfully on my computer and got it's terminal commands to process. So by that, I know go is on my computer.
I have been looking for a good IDE and found https://code.google.com/p/liteide/ LiteIDE which was made specifically for Go.
I read that if you already had go installed on your computer then you could use LiteIDE to start building your code right away. I must have read something wrong some where because I cannot get my projects to build at all. I think it there may be a missing/incorrect path and or something is just setup incorrectly.
This is the error I get in the console:
Current environment change id "win64-user"
C:/go/bin/go.exe env [c:\go]
set GOARCH=amd64
set GOBIN=
set GOCHAR=6
set GOEXE=.exe
set GOHOSTARCH=amd64
set GOHOSTOS=windows
set GOOS=windows
set GOPATH=
set GORACE=
set GOROOT=c:\go
set GOTOOLDIR=c:\go\pkg\tool\windows_amd64
set TERM=dumb
set CC=gcc
set GOGCCFLAGS=-g -O2 -m64 -mthreads
set CXX=g++
set CGO_ENABLED=1
Command exited with code 0.
First_Lite_Go_Proj [C:/go/src/First Litel Go Proj]
Error: process failed to start.
I checked the C:/go directory to make everything there is correct and it was. Also I'm using 64bit windows 7 and double checked that as well.
Any ideas? Mine are: Missing/Incorrect Paths, Can't access a certain directory due to restrictions.
While I have not tested this in Windows 7, on Windows 10, these were the steps that I took to make LiteIDE work
Installed Go to C:\Go
Added C:\Go\bin to PATH and made sure go was working from Command Line
This was the most important step for me. Defined GOPATH in an environment variable. In my case, it was C:\Users\vivek\Documents\Source\Go. I also made sure that there were three folders src, pkg and bin were created in GOPATH. At this point go env was showing me correct values for GOPATH and GOROOT. go get, go build and go install was working as well at this step.
Downloaded and unzipped LiteIDE to C:\liteide. Started LiteIDE and it worked out of the box for me. Make sure that GOPATH is seen correctly by LiteIDE by going to View > Manage GOPATH
Hope this helps. Good luck.
It's not a good idea to keep your projects in the GOROOT path, which per default (when installed using the MSI installer) is C:\Go. Always keep it separated from there. It also helps to avoid issues with updates.
Since Go projects are made up of packages which are organized in directory structures it is important to follow a few rules and keep the working space for your Go projects separated and clean.
In my opinion its best practice to create ONE working directory as the root for ALL your Go projects somewhere in your user space and stick to it.
One way to do this is to create a directory like "work" and set the environment variable GOPATH to it (e.g. C:\Users\Peter\Documents\work). Make sure to relog or restart your computer after your changes.
Upon certain operations Go will automatically create the directories bin, pkg and src below your GOPATH.
src contains your created or downloaded Go source files,
pkg contains your installed package objects, and
bin contains your installed executable files.
bin or pkg will automatically be created when you use the go install command to install a binary executable or a package. It's important to understand that these are files that are not part of the Go installation.
src, if it does not yet exist, will automatically be created the first time you issue a go get command or in case of LiteIDE, the first time you create a new Go1 Command Project or Go1 Package Project. Watch the "Location:" field on the dialog box, it should include your path defined in GOPATH followed by \src (e.g. C:\Users\Peter\Documents\work\src).
In the name field enter the path you want to use for your project. If you plan to track the development of your project on Github (or other repo) it's common practice to include the path to the Git repo in your source path (e.g. github.com/petergloor/hello-go).
Of course you can use any other structure to organize your projects as long you make sure they fall below the src directory in your GOPATH.
For more information about Go workspaces read https://golang.org/doc/code.html#Workspaces.
A final note about the GOROOT environment variable. Dont explicitly set this if you install Go in C:\Go. It's enough to include C:\Go\bin in your path and to set GOPATH. GOROOT is only needed in case Go is installed at another location.
I also had this problem first, but after completing the installation process, I succeeded.
Step 1:
Run (Ctrl+R) -> run target, request build first.
BuildAndRun(Ctrl+F7) -> build and run target
FileRun(Alt+F6) -> go run
step 2:
Check Config via this URL:
https://www.goinggo.net/2013/06/installing-go-gocode-gdb-and-liteide.html
Try setting up the GOROOT to the directory where go was installed. It worked for me.
Do you have 'Install' keyword in your project name? Try remove it.
You have to setup LiteIDE variables correctly (if there are not by default).
Please, check two options:
Go to Settings → "Manage GOPATH"
Options → LiteEnv (there are
environment definitions files). Just double click on someone and
setup Go environment variables.
I'm not sure how this works, but it worked in my case. I got this idea from this video on Youtube-Chris Hawkes
Open LiteIDE.
Click File---New.
Select "Go1 Command Project".
Browse the desired path.
Select the desired folder.
Name the folder and click Ok.
Now, you will be able to see a "main.go" file opened in the IDE.
Write whatever code you want to run in this file with correct syntax, it will run.
The only problem with this is, whenever I create another ".go" source code file in the same folder, the same error is shown. So, you might have to edit this file every time, you try to write new code.