I am trying to get syntax highlighting for C++ code working in Emacs using flymake. I know that with the standard flymake configuration for C++ it will try and run make syntax-check, however, my build system does not use a Makefile (or at least not directly). It uses rosmake which is a wrapper over cmake for the ROS system.
In order to get around the fact that I don't have control over the Makefile I've been trying to add a custom flymake checker based on the flymake website and this stackoverflow question.
I've created the command g++ -Wall -Wextra -fsyntax-only -Iinclude_dir file_to_check.cpp. When I run the command in bash I get the expected output. With no syntax errors I have an exit code 0 and no output. With syntax errors I have an exit code 1 and errors listed by line. However, whenever I try to run this with flymake I get a CFGERR and am told that flymake has been disabled.
I'm pretty sure that the correct command is running because the error displays the full command and everything looks the same as what I type in the terminal. I turned the logging level all the way up to 3 in order to see what the problem is. There is an error about halfway through the log
file /home/rhololkeolke/ros_workspace/team-hku-drc/robot_code/state_trigger/src/Broadcaster.cpp, init=flymake-cc-init [3 times]
create-temp-inplace: file=/home/rhololkeolke/ros_workspace/team-hku-drc/robot_code/state_trigger/src/Broadcaster.cpp temp=/home/rhololkeolke/ros_workspace/team-hku-drc/robot_code/state_trigger/src/Broadcaster_flymake.cpp
saved buffer Broadcaster.cpp in file /home/rhololkeolke/ros_workspace/team-hku-drc/robot_code/state_trigger/src/Broadcaster_flymake.cpp
started process 14517, command=(g++ -Wall -Wextra -fsyntax-only -std=c++0x -I/home/rhololkeolke/ros_workspace/team-hku-drc/robot_code/state_trigger/include -I/home/rhololkeolke/ros_workspace/team-hku-drc/robot_code/state_trigger/msg_gen/cpp/include -I/home/rhololkeolke/ros_workspace/team-hku-drc/robot_code/state_trigger/srv_gen/cpp/include -I/opt/ros/fuerte/include
Broadcaster_flymake.cpp), dir=/home/rhololkeolke/ros_workspace/team-hku-drc/robot_code/state_trigger/src/
received 40 byte(s) of output from process 14517
file /home/rhololkeolke/ros_workspace/team-hku-drc/robot_code/state_trigger/src/Broadcaster.cpp, init=flymake-cc-init
parsed 'g++: error: : No such file or directory', no line-err-info
file /home/rhololkeolke/ros_workspace/team-hku-drc/robot_code/state_trigger/src/Broadcaster.cpp, init=flymake-cc-init
process 14517 exited with code 1
cleaning up using flymake-simple-cleanup
deleted file /home/rhololkeolke/ros_workspace/team-hku-drc/robot_code/state_trigger/src/Broadcaster_flymake.cpp
Broadcaster.cpp: 0 error(s), 0 warning(s), 0 info in 0.07 second(s)
switched OFF Flymake mode for buffer Broadcaster.cpp due to fatal status CFGERR, warning Configuration error has occured while running (g++ -Wall -Wextra -fsyntax-only -std=c++0x -I/home/rhololkeolke/ros_workspace/team-hku-drc/robot_code/state_trigger/include -I/home/rhololkeolke/ros_workspace/team-hku-drc/robot_code/state_trigger/msg_gen/cpp/include -I/home/rhololkeolke/ros_workspace/team-hku-drc/robot_code/state_trigger/srv_gen/cpp/include -I/opt/ros/fuerte/include
Broadcaster_flymake.cpp)
The main error appears to be parsed 'g++: error: : No such file or directory', no line-err-info. I thought it might be because the Broadcaster_flymake.cpp never got created but I checked that and it seems to be working. I get these errors regardless of whether or not there is a syntax error. I can't figure out why it can't find the file as copying and pasting the command into Bash works perfectly. I also tried (shell-command "g++") in an buffer just to make sure that emacs was finding the g++ binary and it is.
If you have any idea why flymake is failing to run the command please let me know. Thank you.
I figured out what the problem is. I overloaded the function flymake-get-project-include-dirs. In that function I was running the rospack cflags-only-I command to get the current ROS package's necessary include directories. What I didn't realize is that the final include directory included a newline character at the end after I had finished processing the output of the rospack command. When I was seeing the command it was trying to run in the buffer I noticed that the filename it was trying to check was always on a new line but I thought that was just a formatting thing.
Now that I've removed all newlines from my include directories everything is working great.
Related
yesterday I had SumatraPDF and VisualStudioCode with latex-workshop working with forward and reverse-search. Today the reverse-search didn't work any more. With a simple bat file I tried to show the commandline arguments.
echo %*
pause
They seemed correct and when I copied the command and paste it into a new cmd it works. To do further testing I tried to direct command and run it.
"C:\....\Code.exe" -g "%1:%2"
pause
Visual Studio Code responds: bad option -g
In SumatraPDF I set cmd as command.
Now the behavior is that I have two cmd windows. With the cmd directly opened the VSC open's the file. With the cmd launched indirect I got the error message.
I have tried resetting the environment variables, changing the current working directory, and checking the code page currently in use.
How can it be that cmd behaves differently with seemingly the same environment? And what can I do to make a cmd started from an application work like a cmd started by windows?
Update: It appears there were a couple of recent security changes in the way VSCODE.exe is allowed to interact with the command line (especially affecting LaTeX-workshop users) so for recent changes twice this year see the discussion at https://forum.sumatrapdfreader.org/t/inverse-search-not-performed-for-vs-code-exe/4486/27
Within SumatraPDF the reverse syntex command for %1 is replaced by %f for file and (l)L for line
It is triggered by a double click near the line of interest and if the synctex index file was compiled correctly by PdfLaTeX (or similar) it will include the tex %f(ilename) and the nearest %l(ine) reference to the point where double clicked.
Thus your tex syctex enhanced "reverse search" call out of SumatraPDF should historically be
"C:\...path to...\Code.exe" -g "%f:%l"
that's Lower L not 1
Avoid using any depreciated -inverse-search parameter from a LaTeX editor just add it once into SumatraPDF-settings.txt and then it's not disturbed by repeated assignments when running your -forward-search.
It will NOT work if the file.synctex or file.synctex.gz is corrupt by a bad PDF compilation.
HOWEVER It seem Microsoft have added the requirement to add a CLI.js handler and requires another switch setting after that ! (see link to discussion in Update above)
For a small test file download https://github.com/GitHubRulesOK/MyNotes/raw/master/AppNotes/SumatraPDF/LATeX%20and%20Reverse-Search.zip unpack and open sync.pdf in SumatraPDF to test that double click on page opens sync.tex in the editor
If the message is cannot start ... then the command line is not configured correctly. A rough test for a bad synctex is to see what happens if the call is changed by adding cmd /k echo to the start, since that will confirm the reverse command. Here I wrote "wrong" as the path to code.exe, once corrected I can remove cmd /k echo.
For some other systems where the reverse might change
see https://github.com/sumatrapdfreader/sumatrapdf/issues/1197#
However there should be no interference in a valid VsCode call.
I am trying to mex a file in a script. The C file which has to be mexed is generated in one of the previous steps of the script before it is mexed.
When I use the below line in the script, everything works fine and the script runs successfully.
mex (strcat(component_name,'_s_func','.c'));
but when I add the same line below with
mex -g (strcat(component_name,'_s_func','.c'));
it gives me the error
C:\PROGRA~2\MATLAB~1\BIN\MEX.PL: Error: '(strcat(component_name,_s_func,.c))' not found.
Any idea why its not able to find the same file while using -g while it can find it when using without -g option?
The problem with your statement is that with the syntax
mex -g [...]
MATLAB assumes you are calling mex with the string arguments '-g' and '[...]' so it assumes that your file is called (strcat(component_name,'_s_func','.c')) and does not execute the command.
You can either use the solution you posted with eval, as that way you again call it with the strings '-g' and 'filename.c'. Another possibility would be to use the syntax
mex('-g',strcat(component_name,'_s_func','.c'));
because that way the command strcat is really executed before calling mex.
--
This is the same behavior as e.g. with clear. As you might know, the following statements are equal:
clear a b c
clear('a','b','c');
ok its possible to do this with eval command
file_name=(strcat(component_name,'_s_func','.c'));
eval(['mex -g ',file_name]);
I'm compiling my matlab .m functions (and mex files) to run as a standalone program on a Linux server. In the end, I manage to compile all files and even run them, although in the process I do get some warnings:
Warning: Adding path "input_folder1" to Compiler path instance.
Warning: Adding path "input_folder2" to Compiler path instance.
Warning: Adding path "input_folder3" to Compiler path instance.
Basically, my question is what is causing these warnings and how can I avoid them?
And, can I run into trouble if I move this standalone program to a different server?
The mcc line that is causing these warnings is:
mcc -m -d output_folder -I input_folder1 -I input_folder2 -I input_folder3 -a mex_file1.mexa64 -a mex_file2.mexa64 MainScriptFile.m SubFunction1.m SubFunction2.m SubFunction3.m
These warnings are caused by a missing path. If you want to shut them off, you can either disable them using warning off or add the input_folders to the Compiler path before compiling. But since mcc does that anyway (and displays a warning), you can safely ignore them.
Basically, they're just mcc telling you "Couldn't you have done that to start with? Now I'll have to do it myself...".
I can't answer your second question the way it is worded, so I'll have to go with this: You will not run into trouble caused by these warnings or any implications. If you do run into trouble, it's for a different reason.
Is it possible to integrate Cppcheck with Emacs in a more sophisticated way than simply calling the shell command on the current buffer? I would like Emacs to be able to parse Cppcheck's messages and treat them as messages from a compiler (similar to how compile works), such as using C-x ` to visit the targets of Cppcheck's messages.
Here is some example output Cppcheck:
$ cppcheck --enable=all test.cpp
Checking test.cpp...
[test.cpp:4]: (error) Possible null pointer dereference: p - otherwise it is redundant to check if p is null at line 5
[test.cpp:38]: (style) The scope of the variable 'i' can be reduced
[test.cpp:38]: (style) Variable 'i' is assigned a value that is never used
[test.cpp:23]: (error) Possible null pointer dereference: p
[test.cpp:33]: (error) Possible null pointer dereference: p
Checking usage of global functions..
[test.cpp:36]: (style) The function 'f' is never used
[test.cpp:1]: (style) The function 'f1' is never used
[test.cpp:9]: (style) The function 'f2' is never used
[test.cpp:26]: (style) The function 'f3' is never used
Hmmm... I think this is really simple actually. Just use 'compile', as in M-x compile, and type as the compile command:
cppcheck --template='{file}:{line}:{severity}:{message}' --quiet <filename>
Where the filename is the name of the file on which you wish to run cppcheck. That puts the output of cppcheck into a form that the compilation buffer can parse and gives you the full functionality you get with, for instance, a g++ compile.
The --quiet is probably not necessary but since all I care about are the errors that's what I use.
You can use flymake which ships with Emacs.
The basic idea is to write a flymake command that runs cppcheck and then massages the output into a format the flymake can use. If you then enable flymake in your c++ mode buffers, you'll get on the fly error highlighting.
This is an example of flymake working with my Python buffers using pyflakes.
flymake in general expects output in this form
filename:line_number: class: message
Where filename is the name of the file, number is the line number, class is a string like error or warning indicating the type of message and message is a string indicating the actual error. cppcheck output looks close to this. You should probably write a little wrapper to convert the output of cppcheck to this format and then add a hook to turn on flymake for c++ mode.
With C, adding something like gcc -Wall -o nul -S ${CHK_SOURCES} to your Makefile with under a target check-syntax and running flymake-mode does what's necessary. I think it'll be similar for c++ mode.
For the gory details, you should check out http://flymake.sourceforge.net/
Is it possible to integrate Cppcheck with Emacs in a more sophisticated way
Yes, it is possible. Use flymake. I'm surprised no one has done this yet for cppcheck.
No problem, you can do it yourself. Add cppcheck as a new flavor of flymake tool. To do that, follow an existing example. It's not too complicated to do, but coming in cold, it's hard to know what to do. (I've never seen a guide document that describes how to integrate new tools into flymake). Following an existing working example solves that.
Here's a 7k file that adds PHP CodeSniffer as a flymake tool. http://www.emacswiki.org/emacs/flyphpcs.el
Most of that 7k is comments...
You should be able to modify that to add any arbitrary tool to flymake. The key steps are:
Associate your target file extension (example: .cpp) with a pair of functions (init and cleanup) that do your flymake stuff.
define a function to generate the command line, each time flymake scans your buffer. Ths fn gets the name of the file backing the buffer, and produces a command line. In your case it would run cppcheck with all the appropriate command line parameters. The fn that generates the command line is called by the init fn referenced in #1.
define a regex that matches error messages generated by your tool, and add that regex to the flymake list. This allows flymake to extract error messages from the output of the tool you run. By parsing the output, flymake can get the line numbers and highlight broken lines in your buffer.
based on the answers, flymake sounds good.
you can write a cppcheck parser but it sounds easier to use cppcheck --template option.
cppcheck --template="{file}:{line}:{severity}:{message}" foo.cpp
might match flymake pattern. It is just an idea.
The quickest way is probably to use flymake and add an extra target to your makefile.
This setup is working for me:
check-syntax: cppcheck
g++ -o nul -S ${CHK_SOURCES} $(CFLAGS)
cppcheck:
cppcheck --enable=all --quiet --template={file}:{line}:{severity}:{message} ${CHK_SOURCES}
I'm trying to get flymake to work, but when I run flymake-mode, I get the following error
switched OFF Flymake mode for buffer TdDisassemblerIde.cpp due to fatal status \
PROCERR, warning Failed to launch syntax check process 'make' with args (-s -C ./ \
CHK_SOURCES=TdDisassemblerIde_flymake.cpp SYNTAX_CHECK_MODE=1 check-syntax): Wrong type \
argument: symbolp, (utf-8)
Any clues?
When I have a problem with flymake, I do
M-x set-variable flymake-log-level <RET> 3
And then run flymake again (M-x flymake-mode).
Then look in the *Messages* buffer for a useful error message.
The last time this happened to me, about an hour ago, my check-syntax target in the flymakefile lacked a source module; I had added a module but had forgotten to add it to the list of files that should be included in a flymake compilation. Modifying the makefile corrected it. (This was for C#, but setting flymake-log-level should work to get a diagnosis for you too.)
Answering my own question: the problem was that I had set process-coding-system-alist to contain the symbol utf-8, and apparently flymake does not like that. Setting process-coding-system-alist to nil solved the problem.