I have some problems while scanning a mixed C#, C++ solution with SonarQube.Scanner.MSBuild.exe. (during the SonarQube.Scanner.MSBuild.exe end) So I want to ask if there is a verbose option to activate enhanced/debug output.
The output is that a file is not found, but there is a additional subfolder in the path that is not correct, and I want to understand where it comes from.
Example: a.cpp is located on C:\src\ProjektA\Modul1, but the output says:
"Warn: Cannot find the file "C:\src\ProjektA\**Modul2**\Module1\a.cpp" skipping violations"
By the way: in FilesToAnalyse.txt the path is correct
To activate verbose mode, you simply need to pass the following argument:
/d:sonar.verbose=true
Reference: https://docs.sonarqube.org/display/SCAN/Additional+Analysis+Parameters
Related
want to suppress all error checks in some file. My command line command is
cppcheck --enable=all -j 4 --output-file=out.txt --project=solution.sln --suppress=*:file.cpp
But I got errors from file.cpp in my output file. I used to have quite similar(as far as I recall) command line before and it suppress all checks in the file, but ,u some reason now it doesn't work now. Is my command line wrong?
I know can use suppression file, but I prefer command line parameter and also want to figure out what am I doing wrong.
The suppression needs to match the file path as shown in the result.
If you specify a relative folder/file to check that is straight forward and you can just use the structure from your current folder.
But if you are checking with --project or an absolute path you need to specify -rp (as in "root path") to tell Cppcheck where to base the file paths from. In your case just adding -rp=. should fix the issue - at least it will change the paths in the result from absolute ones to relative ones which are the ones you have to use in your suppression.
This is driving me crazy, I must admit. After finally being able to successfully compile two functions I need to process voice files, from C/C++ code that I downloaded from a trustworthy online repository (code that had been thoroughly tested in Linux), I am now struggling to launch those files from Matlab...
When I type the following command in cmd (dos)
Analysis b2.wav config_default
it works, no problem (see here Works).
Then, I build the exact same command into a string and feed it to the "system" Matlab function. Then the code crashes... (see here Fails) I've tried with full paths (c:\b2.wav, etc) but still does not work...
Any ideas as to why this might be happening?
Your image shows that the program Analysis stopped unexpectedly.
It might be a lot of reasons why, so let's go step by step:
1) Try executing Analysis from Terminal and passing wrong parameters (a file that doesn't exist, only one param (missing the config_defalut), no parameters at all, three parameters, etc...)
Can you make the program crash from terminal by passing wrong params?
2) Try creating the command first, checking that it's correct (\b is actually \b instead of a string modifier)
command_to_be_run = 'C:\Analysis C:\b2.wav C:\config_default'
disp(command_to_be_run) % is it showing exacly what you want?
system(command_to_be_run); % if so, run it.
3) Try creating a dummy executable dummy.exe in C that accepts two parameters and prints the received parameters (keep it super simple, just printing). Call it from Terminal. Does it work? Call it from Matlba. Does it Work?
With this 3 tests you can considerably narrow down where your error comes from.
By the way, is "config_default" a file or just a string that tells analysis how to behave? In some examples you treat it as a file, in others as a parameter without path.
Based on what's been tried so far and the outputs, here's my theory:
Premise: Analysis.exe came from code that's well tested in Linux. It works in Windows command line when run from the same directory where both it and the target file reside. But it stops working from Matlab console.
Assertion 1: Matlab console does not operate within the context of the directory where the binary is but rather within the Matlab directory. As such, Analysis.exe will try to find the target from the Matlab directory.
Validation for Assertion 1: Try putting the binary and the target wav in the Matlab directory. Then run system with the binary and target specified just by name (no path).
Assertion 2: If the file's full path is specified to address this issue, it still doesn't work. This may be because the code assumed a Linux file system where the delimiter is "/" rather than "\".
Validation for Assertion 2: Run with paths specified from the command line while in a diferent directory to see if it fails or not.
Possible Solution 1: Add the directory where both Analysis.exe and the target are into the Matlab path: (1) On the Home tab, in the Environment section, click Set Path. Add the path there. (2) addpath (folderName1,...,folderNameN) adds the specified folders to the top of the search path for the current MATLAB session. -> Then run the system command without the full paths.
Possible Solution 2: Add the directory where both Analysis.exe and the target are into the Windows environment path. Then run the system command without the full paths.
EDIT: Possible hackish solution - Create a batch file where: (1) you would cd to the directory where Analysis.exe and the target wav are; and (2) do a Matlab system call to the batch file.
EDIT 2: Possible experiment to validate assertion 2.
I need to run a program that requires certain inputs that are listed in a input.txt file. I want to be able to call up this file when I execute the program so I can modify the input.txt file if needed before executing the rest of the code.
I'm running on Mac OS X.
What I have is:
call system('notes input.txt')
I get the following message :
sh: notes: command not found
Is there a special way to call the app notes, or is my error somewhere else?
you're not specifying a full filesystem path in the string ("notes input.txt") which the SYSTEM function sends to a command shell. That means you're hoping there's a binary named "notes" somewhere in your shell's $PATH , and your shell is telling you that's not true. The Notes app is not named "notes", and it doesn't live somewhere pointed to by the shell's $PATH. That's why you get this error message. Try passing to the shell the full path of both the binary you want to run, and the file you want to edit:
CALL SYSTEM("/Applications/Notes.app/Contents/MacOS/Notes /path/to/input.txt")
(NB: that path is where the Notes app lives on my Mac; YMMV.)
Try
call system("/Applications/TextEdit.app/Contents/MacOS/TextEdit /path/to/input.text")
The /Applications/TextEdit.app location is a bit misleading as it is actually a folder. In Finder if you option-click on it you can select to view contents (Not sure of the exact wording of the option as I don't have my mac on me at the moment). Alternatively, cd /Applications/TextEdit.app; ls to view the contents. The executable should be stored in a subdirectory as shown above.
I am trying to compile a section of a library with cmake and make. I am getting the error when I run Make that the include is failing:
/home/user/Sean/PCL/pcl/apps/src/face_detection/openni_face_detection.cpp:9:57: fatal error: pcl/apps/face_detection/openni_frame_source.h: No such file or directory compilation terminated.
I know that with gcc, you can get the compiler to read to you where it looked for the include, but is there a way to accomplish this with make and cmake.
If the Makefile is automatically generated by CMake, you can launch make like this:
> make VERBOSE=1
to interleave the progression on targets with the actual commands make is executing.
From these commands you should be able to extract the current include paths.
You may probably want to take also a look at the include_directories CMake command,
in case some include paths are missing.
I'm cross-compiling a Win32 target on SUSE Linux using mingw32. None of the conventional verbose/debug options provided the #include search path.
This forced my (lazy) hand to manually reproduce the compile operation that ultimately revealed the header search path.
A brief description...
Run the make operation and take note of the compiler, the directory, and the command line it's executing. Yeah, it's messy, but not impossible. Capture the output to a file if headless.
Change into the directory
Execute the compiler with the --help option. Take note of its verbose option.
Run the compile command specifying the verbose option.
Here's what I got...
#include "..." search starts here:
#include <...> search starts here:
/home/me/rpmbuild/BUILD/the-app-0.0.0/core/src/win32/include
/home/me/rpmbuild/BUILD/the-app-0.0.0/core/src/win32/compat/include
/home/me/rpmbuild/BUILD/the-app-0.0.0/core/src
/home/me/rpmbuild/BUILD/the-app-0.0.0/core/src/win32/generic
/home/me/rpmbuild/BUILD/the-app-0.0.0/core/src/win32/filed
/usr/lib64/gcc/x86_64-w64-mingw32/8.2.0/include/c++
/usr/lib64/gcc/x86_64-w64-mingw32/8.2.0/include/c++/x86_64-w64-mingw32
/usr/lib64/gcc/x86_64-w64-mingw32/8.2.0/include/c++/backward
/usr/lib64/gcc/x86_64-w64-mingw32/8.2.0/include
/usr/lib64/gcc/x86_64-w64-mingw32/8.2.0/include-fixed
/usr/x86_64-w64-mingw32/sys-root/mingw/include
End of search list.
Not too bad...
BTW, this is a cmake 3.5.2 configuration.
I face with a problem in linking phase, while working with MSVC9 . It says:
NMAKE : fatal error U1095: expanded command line link.exe . . . too long
You can get nmake to write the command line arguments to a file, then use the link option to read the arguments from the file.
Look for "inline files", eg http://msdn.microsoft.com/en-us/library/z440c98k(v=vs.80).aspx
It's a very long time since I did this, but as I recall the usage is something like:
foo.exe : foo1.obj foo2.obj foo3.obj
link.exe #<<
foo1.obj
foo2.obj foo3.obj
... more arguments, macros etc on one or more lines
<<
rem other commands go here if you want
Essentially you just have an ordinary nmake command line, but the pair of << markers tell nmake to write the options to a file (and they are replaced by the name of that file), and then # tells link to read arguments from that file.
The KEEP option (possibly with a specified file name) can be useful for debugging - if link barfs, you can look in the file to see what you actually passed to it.
There's not much you can do about fixed command line lengths in your tools. You might like to try and combine your object files into a couple of libraries, and then perform the final link and link the libraries together. This will introduce another step into your Makefile, but will get around the command line too long error.
lol that sucks but we need more information to answer your question. OS for starters, basically, it is saying that the command line to call the linker is bigger than the buffer allows in cmd.exe itself. If i remember correctly there may be a way to make the command shell utilize a bigger buffer on the command line. Or you can possibly change the shell to windows powershell and see if that might work.