Errors not detected when g++ is not in system path (Windows) about linter-gcc HOT 27 CLOSED

I see you have a space in your path. That could be the issue. Could you try setting ExecPath again, wrapping your path in double quotes?

from linter-gcc.

If I add double quotes around the ExecPath setting, it reports "No Issues" even when g++ is also in the system path. Weird.

I have tested the following values:

"C:/Program Files/mingw-w64/x86_64-5.1.0-posix-seh-rt_v4-rev0/mingw64/bin/g++"
C:/Program\ Files/mingw-w64/x86_64-5.1.0-posix-seh-rt_v4-rev0/mingw64/bin/g++
"C:\\Program Files\\mingw-w64\\x86_64-5.1.0-posix-seh-rt_v4-rev0\\mingw64\\bin\\g++"
C:\\Program Files\\mingw-w64\\x86_64-5.1.0-posix-seh-rt_v4-rev0\\mingw64\\bin\\g++
C:\\Program\ Files\\mingw-w64\\x86_64-5.1.0-posix-seh-rt_v4-rev0\\mingw64\\bin\\g++
"C:\Program Files\mingw-w64\x86_64-5.1.0-posix-seh-rt_v4-rev0\mingw64\bin\g++"
C:\Program Files\mingw-w64\x86_64-5.1.0-posix-seh-rt_v4-rev0\mingw64\bin\g++

Let me know if I can provide any more testing to help fix this problem.

from linter-gcc.

I think I might know what the problem is. It's possible g++ is being given invalid parameters. Could you check the parameters reported in the javascript console? You can open the console using Ctrl+Shift+I on linux, but I'm not sure how to do it on windows. Could you report the parameters reported in the console? Also, try combining the parameters you see in the console and run them on cygwin or something and make sure g++ is happy with them. If g++ is given invalid parameters, it'll just say 'unrecognized option' and you won't get any errors reported by the linter.

from linter-gcc.

I think you are onto something. The parameters are "-Wall", "-std=c++11", "-fmax-errors=15", "-I ", and the last one is the full path to the source file. When I run g++ from the command line using these parameters, that one that gives me trouble is "-I ". When that parameter is included, I get the following error message: g++: fatal error: no input files. If I remove the -I, the last parameter is properly detected as the input file.

I am using g++ version 5.1.0 if that makes a difference. Thanks.

from linter-gcc.

Ok I think I know what the problem is. It looks like your include paths parameter is comprised only of spaces. To test this, could you make sure your include paths is completely empty and see if you get linting? One way to do this is to press Ctrl+A with the cursor inside the 'include paths' text box and delete everything. Once we know this is the problem, I will push an update that trims leading and trailing spaces from this parameter.

from linter-gcc.

Interestingly, having "-I " as a parameter to g++ on linux doesn't cause problems - the linting still works fine. In any case, I will update the code to do the trimming.

from linter-gcc.

Ok just pushed the update. Now if you look at the parameters, you'll find that having an empty 'include paths' or one comprised only of spaces means the "-I" parameter is left out. I would be grateful if you could update to the latest version and confirm that it's working so I can close this issue.

from linter-gcc.

Thank you for your quick work! However, I just tried your update and have the same problem. The errors/warnings are displayed when g++ is in the system path, but not when it is just in the Exec Path. Also, the Exec Path must not contain double quotes around it. Here is the output from the developer console (main.js:148 and 149):

C:\Program Files\mingw-w64\x86_64-5.1.0-posix-seh-rt_v4-rev0\mingw64\bin\g++
["-Wall", "-std=c++11", "-fmax-errors=15", "C:\Source\Demos\FileDemo\createFile.cpp"]

Also, I checked to make sure the "Gcc Include Paths" field is empty (not spaces or paths).

from linter-gcc.

This is interesting. Clearly, the "-I" parameter is no longer there, but you're still having problems. Could you try running the command by stitching together the parameters in the console? It all looks fine to me really, and it should work.

from linter-gcc.

I think have have tracked to problem down. g++ needs access to its libraries, which are located in the same directory as g++. Therefore, if I call g++ without this directory in my path, g++ complains about missing libraries (dlls).

The issue is really a side effect of my system and not your linter. Sorry for sending you on a few rabbit trails there.

My setup for g++ using mingw-w64 is fairly common. A nice additional feature for other Windows users (and me) might be to have a setting to specify the path to g++'s directory, rather than g++ itself. Then the linter would call g++ in an environment that includes that whole directory. I don't know enough about the Atom (or the linter package) API to say that my suggestion is possible.

Thank you for being so responsive.

from linter-gcc.

I think I have a solution for you. g++ has an option "-L" which allows you to add library directories. Could you try using that option to remedy the library issue? I think it's probably a good idea for me to add this option to the linter anyway. Please let me know how you get on.

from linter-gcc.

The -L did not work in my tests. I think this parameter lets g++ know where to look for libraries that the linker needs to include in the executable, but the problem is that g++ does not have access to dynamic libraries that it needs to run.

From the command line, I need to update the path before I run g++
SET PATH=C:\Program Files\mingw-w64\x86_64-5.1.0-posix-seh-rt_v4-rev0\mingw64\bin;%PATH%;

Most Window's programmers open up a "developers command prompt" that adds the appropriate additions to the path at startup. I am not sure how you could do something like that from a plugin.

from linter-gcc.

Hello again, and sorry for disappearing for a little while. I don't think it's a good idea to make the plugin modify the user's path variable. I think I'll add a note in the README for Windows users informing them that g++/gcc needs to be in the their path so it can find the libraries it needs. What do you think?

from linter-gcc.

I agree, the plugin should not modify the user path. I was hoping g++ could execute with a custom path, without modifying the user path. I know you can modify the path for a specific command-line instance and I see there is a node.js variable, process.env, that supports this, but I am not sure the linter API is that flexible. Again, I have never written an Atom package.

At minimum, adding a note to the README is a great idea. It would also be nice to put a note for Windows users right in the plugin setting by the exec path.

from linter-gcc.

Hello. It looks like the issue you brought up is slightly more complicated than we thought. Linter-gcc, like some other linters, uses a helper npm package called atom-linter to execute GCC and parse the errors. There has been a discussion on atom-linter's issue page about the path issue, and in the end it was decided to wait for the issue to be fixed in Atom itself, as the existing solutions are not ideal. The atom-linter issue is here and the main Atom discussion is here.

Having this issue corrected in Atom itself makes much more sense, because a lot of packages run external commands, and all of these packages would be affected by the inability to use the $PATH variable.

In any case, I will push an update this evening that cleans up linter-gcc's settings, and I will add a note to the execpath setting for Windows/OSX users. Also, I am reopening the issue. Let's leave it open until this issue is resolved in Atom.

from linter-gcc.

Sounds good! Thank you for the links to the other relevant issues.

from linter-gcc.

Hello. Just wanted to let you know that I've just pushed an update that makes linter-gcc detect command-line errors such as invalid flags. I was thinking this would help with the path issue because it should show up as an error. Let me know if it doesn't work. To trigger it, you can simply enter an invalid flag in the C++ flags field in the package settings.

from linter-gcc.

That is very helpful, thank you!

Could the linter also output message if the GCC Executable Path is incorrect?

When g++ cannot be found by the linter, I get "No Issues." However, I notice that when linter-gcc tries to execute g++, the following message is processed as output:

"'g++' is not recognized as an internal or external command,
operable program or batch file.
"

My guess is that it does not trigger an error, because it does not have the word "error" in the string.

from linter-gcc.

Hmmm that's interesting. On Linux, entering an invalid executable path triggers an atom error notification (see here for info). Internally, linter-gcc uses an npm package called atom-linter to run GCC and parse its output, so this should really be handled by atom-linter. Having said that, however, I will try to incorporate this functionality using another package to detect the presence of an executable in a platform-independent way.

from linter-gcc.

@hebaishi atom-linter is just an interface to the underlying BufferedProcess and BufferedNodeProcess API exposed by Atom. and those classes too rely on Node core to determine if a file/folder was found or not.

If I had to guess, the user's shell is not passing correct exit codes

from linter-gcc.

@steelbrain I think you're right. In the meantime, I could try using the which function in shelljs. I'll play with it and see how well it works on windows.

from linter-gcc.

Things seem to be working with shelljs. Update coming soon.

from linter-gcc.

@stretchtiberius added $PATH expansion using shelljs. I would be grateful if you could try it and let me know if it works.

from linter-gcc.

@hebaishi Just a side note that if it was a $PATH related problem then it's already been work-arounded in the latest atom-linter, https://github.com/AtomLinter/atom-linter/blob/master/CHANGELOG.md#420

from linter-gcc.

@steelbrain thanks for that. I will update linter-gcc's dependency list so the latest version of atom-linter is installed.

from linter-gcc.

It works! In Windows when I don't have g++ in my system path, I now get a popup error message stating that g++ was not found, instead of a silent failure.

from linter-gcc.

$PATH expansion now works correctly both on Windows and Linux and when linter-gcc fails to find the executable, a helpful error message is displayed.

from linter-gcc.