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.
Related
I have a CMakeLists.txt.
I use it for generating a makefile with ccmake.
Then upon make, my sources are compiled ok.
At link time, the command line produced is essentially
/opt/rh/devtoolset-6/root/usr/bin/c++ myprog.cc.o -o myprog -Ldir3 -L/opt/rh/devtoolset-3/root/usr/lib/gcc/x86_64-redhat-linux/4.9.2 ... -Wl,-rpath,dir4:dir5:/opt/rh/devtoolset-3/root/usr/lib/gcc/x86_64-redhat-linux/4.9.2 ...
The two spots specifying the search path
/opt/rh/devtoolset-3/root/usr/lib/gcc/x86_64-redhat-linux/4.9.2
should actually point to
/opt/rh/devtoolset-6/root/usr/lib/gcc/x86_64-redhat-linux/6.2.1
How can I fix this?
I have devtoolset-3 in my system, but I do not know where this search path is set, or how to change it.
I actually expected that to take place automatically after executing
scl-devtoolset-6
(in my .bashrc), the same way the correct version /opt/rh/devtoolset-6/root/usr/bin/c++ is detected without me doing anything else.
Of course, I get many linking time errors due to version mismatches.
The only place where I see the search path set is in line
link_directories(${LIBDIR_MY})
in CMakeLists.txt, and LIBDIR_MY points to dir3, which is correctly added in the linking command line.
But I found no place where .../devtoolset-3/... is added.
Possible origins of -L:
link_directories in CMakeLists.txt: checked.
target_link_libraries: Where? What is the expected file name pattern to look for?
link_libraries: Where? What is the expected file name pattern to look for?
CMAKE_LIBRARY_PATH: Checked. It is not set.
A find_package command: See below
Somewhere else?
This How do I add a library path in cmake? does not add to my question.
Update 1:
There was in fact a find_package(mylib) (actually, with a different name) in CMakeLists.txt.
Going to the dir of mylib and issuing find . -name “*” -type f -exec grep /opt/rh/devtoolset-3 {} \; there were two files that matched:
build/CMakeCache.txt:
two occurrences of devtoolset-3
PETSC_LIBRARIES:STRING=...devtoolset-3...
FIND_PACKAGE_MESSAGE_DETAILS_PETSc:INTERNAL=[...devtoolset-3...][YES][v()]
It appears to me that this stems from file CMake/cmake-modules/FindPETSc.cmake (possibly invoked by line find_package (PETSc REQUIRED) in CMakeLists.txt), which has a line
set (PETSC_LIBRARIES ${PETSC_LIBRARIES_ALL} CACHE STRING "PETSc libraries" FORCE)
and many prior lines
set (PETSC_LIBRARIES_<various terms> ...)
Notes:
I do not know where in that file devtoolset-3 is first detected and set.
build/include/summit/mylibConfig.cmake.
I still could not track down what made devtoolset-3 appear here.
I found the culprit.
As hinted at in Update 1 of the OP, the sequence is the following:
Line
find_package (PETSc REQUIRED) in file (1)
CMakeLists.txt forced processing file (2)
CMake/cmake-modules/FindPETSc.cmake.
Line*1
petsc_get_variable (PETSC_EXTERNAL_LIB_BASIC petsc_libs_external) in file (2)
CMake/cmake-modules/FindPETSc.cmake sets a local cmake variable
petsc_libs_external from the value of the variable
PETSC_EXTERNAL_LIB_BASIC read from file (3)
~/petsc-3.8.2/lib/petsc/conf/petscvariables.
PETSC_EXTERNAL_LIB_BASIC is not set explicitly in file (3)
~/petsc-3.8.2/lib/petsc/conf/petscvariables. Line
include ~/petsc-3.8.2/arch-linux2-c-debug/lib/petsc/conf/petscvariables forces reading file (4)
~/petsc-3.8.2/arch-linux2-c-debug/lib/petsc/conf/petscvariables.
Line
PETSC_EXTERNAL_LIB_BASIC = ... -Wl,-rpath,/opt/rh/devtoolset-3/root/usr/lib/gcc/x86_64-redhat-linux/4.9.2 -L/opt/rh/devtoolset-3/root/usr/lib/gcc/x86_64-redhat-linux/4.9.2 -Wl,-rpath,/opt/rh/devtoolset-3/root/usr/lib64 -L/opt/rh/devtoolset-3/root/usr/lib64 -Wl,-rpath,/opt/rh/devtoolset-3/root/usr/lib -L/opt/rh/devtoolset-3/root/usr/lib ... in file (4)
/home/sserebrinsky/petsc-3.8.2/arch-linux2-c-debug/lib/petsc/conf/petscvariables brings the "undesired" directories into the executed command line.
*1 (petsc_get_variable is a macro defined in FindPETSc.cmake)
First off I would like to say I've seen the previous questions on this site, I've tried every solution but none fit my use case or solves my problem.
I am having trouble with the g++ complier being recognized, I've included this path:
C:\Program Files (x86)\mingw-w64\i686-7.2.0-posix-dwarf-rt_v5-rev1\mingw32\bin\g++.exe
which is where the current version of mingw is located (recently downloaded). I've also tried other options like changing the path to gcc.exe, and just regular bin. Someone please provide a detailed solution to this problem.
Other things i have tried and looked at closely would be:
http://stephencoakley.com/2015/01/21/guide-setting-up-a-simple-c-development-environment-on-windows
seeing as though I'm working through sublime text 3
Another thing Ive tried:
Ive tried to copy and paste the path into cmd and run it , but i find this error code:
C:\Users\Kxrk>C:\Program Files (x86)\mingw-w64\i686-7.2.0-posix-dwarf-rt_v5-rev1\mingw32\bin\g++.exe
'C:\Program' is not recognized as an internal or external command,
operable program or batch file.
So seeing that, i tried another way , and that is to drag the file and drop it into cmd and get this :
C:\Users\Kxrk>C:\Program Files (x86)\mingw-w64\i686-7.2.0-posix-dwarf-rt_v5-rev1\mingw32\bin\g++.exe
g++.exe: fatal error no input files
compilation terminated
when u drag and drop the file it has double quotes around it , so i tried editing the path to contain double quotes around it and the path automaticlly changes back after saving.
This was very simple , it was one of those weird cases.
To solve my problem what i did was:
1: uninstall , the current version of the mingw compiler , because i felt as though the one i had was corrupt in a way.
2:Redownloaded it the compiler from the website http://www.mingw.org/
3: set up the new Environmental variable where i save it , witch was C:\MinGW\bin
I had to install g++ from the command line(cmd ,command prompt)
by using this command mingw-get install g++witch is located inside bin on default
now i created one more directory in the environmental variables , C:\MinGW\bin\g++.exe
6.Now everything works , and is normal
If you are trying to run the compiler from the command line then you have to put double quotes around the path, because the path contains two whitespaces (this is the reason for the first error).
The reason for second error is that you didn't specify which C++ program you want to compile. You have to append the filename of your C++ input file to your command:
C:\Users\Kxrk>"C:\Program Files (x86)\mingw-w64\i686-7.2.0-posix-dwarf-rt_v5-rev1\mingw32\bin\g++.exe" program.cpp
See Barmak Shemiranis answer if don't want to enter the full path all the time. After that you can just use this:
C:\Users\Kxrk>g++ program.cpp
You have to use quotation marks around the path so that is treated as a single path:
c:\>"c:\program files\path\g++.exe"
A better way is to set the environment variables. Open Environment variables windows (in Windows 10 you can type in "environment variables" in search box) or right click on "Computer" in desktop, open "Advanced System Settings" and find the button for "Environment variables"
Go to your command propmpt, type set path, it will show list of directories, copy them,
Now type set path=<data you copied> and then add a semicolon and possible directory to g++ usually C:\MinGW\bin
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
I have been given some source code, along with a CMakeLists.txt file, and told to run cmake by:
cmake ../src -DOPEN_NI_ROOT=/home/karnivaurus/OpenNI
I have also noticed that there is a file called FindOpenNI.cmake, which I believe is used when find_package(OpenNI) is called by cmake.
Therefore, I am guessing that OPEN_NI_ROOT is some kind of variable that is used by cmake for the remainder of setup.
However, I have tried inserting the line set(OPEN_NI_ROOT "/home/karnivaurus/OpenNI") into my CMakeLists.txt file, in an attempt to avoid the need to add it as an argument at the command line. But this does not seem to do the same thing.
Can somebody please explain how these two variable types are different?
The file FindOpenNI.cmake is open source and can be found at:
https://github.com/victorprad/InfiniTAM/blob/master/InfiniTAM/cmake/FindOpenNI.cmake
The issue is this line in FindOpenNI.cmake (link):
set(OPEN_NI_ROOT "/usr/local" CACHE FILEPATH "Root directory of OpenNI2")
This will set OPEN_NI_ROOT unless it's already in the cache. A simple call to:
set(OPEN_NI_ROOT "/home/karnivaurus/OpenNI")
does not set the variable in the cache, so it will be overridden when the line in FindOpenNI.cmake is hit. Using the command line form of setting the variable will set it in the cache, which is why it works just fine.
The easiest way to avoid having to set the command line option is to set the cache explicitly in your own CMakeLists.txt:
set(OPEN_NI_ROOT "/home/karnivaurus/OpenNI" CACHE FILEPATH "Root directory of OpenNI2")
If you're working from a dirty build directory, it's likely this cache variable already exists, so this line would have no effect. In that case, either work from a clean build directory, or set the FORCE option:
set(OPEN_NI_ROOT "/home/karnivaurus/OpenNI" CACHE FILEPATH "Root directory of OpenNI2" FORCE)
This will write over the cached value. Note that this would prevent you from setting the option in the command line in the future, which is why this method isn't preferred. You can find some more information about the mechanics of this here.
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.