Is there a way to pass custom file extensions to Cppcheck? For example, *.pc.
sure. cppcheck will check any file that you give it.
check the file xyz.pc:
cppcheck xyz.pc
check all files with extension pc in folder srcfolder (this at least works in linux):
cppcheck srcfolder/*.pc
the --file-list flag may also be useful. you could generate the list of files that you want to check using an arbitrary script. and then run cppcheck on that file list.
cppcheck --file-list=files.txt
Related
Ok, n00b question. I have a cpp file. I can build and run it in the terminal. I can build and run it using clang++ in VSCode.
Then I add gtest to it. I can compile in the terminal with g++ -std=c++0x $FILENAME -lgtest -lgtest_main -pthread and then run, and the tests work.
I install the C++ TestMate extension in VSCode. Everything I see on the internet implies it should just work. But my test explorer is empty and I don't see any test indicators in the code window.
I've obviously missed something extremely basic. Please help!
Executables should be placed inside the out or build folder of your workspace. Or one can modify the testMate.cpp.test.executables config.
I'd say, never assume something will "just work".
You'll still have to read the manual and figure out what are the names of config properties. I won't provide exact examples, because even though I've only used this extension for a short time, its name, and therefore full properties path, has already changed, so any example might get obsolete quite fast.
The general idea is: this extension monitors some files/folders, when they change, it assumes those are executables created using either gtest or catch2. The extension tries to run them with standard (for those frameworks) flags to obtain a list of test suites and test cases. If it succeeds, it will parse the output and create a nice list in the side panel. Markers in the code are also dependent on the exactly same parsed output, so if you have one, you have the other as well.
From the above, you need 3 things to make this work:
Provide correct path (or a glob pattern) for finding all test executables (while ignoring all non-test executables) in the extension config. There are different ways to do this, depending on the complexity of your setup, they are all in the documentation though.
Do not modify the output of the test executable. For example, if you happen to print something to stdout/stderr before gtest implementation parses and processes its standard flags, extension will fail to parse the output of ./your_test_binary --gtest-list_tests.
If your test executable needs additional setup to run correctly (env vars, cwd), make sure, that you use the "advanced" configuration for the extension and you configure those properties accordingly.
To troubleshoot #2 and #3 you can turn on debug logging for the extension (again, in the VSCode's config json), this will cause an additional "Output" tab/category to be created, where you can see, which files were considered, which were run, what was the output, and what caused this exact file to be ignored.
This messed with me for a while, I did as Mate059 answered above and it didn't work.
Later on I found out that the reason it didn't work was because I was using a Linux terminal inside windows (enabled from the features section) and I previously had installed the G++ compiler using the linux terminal so the compiler was turning my code into a .out file, for some reason TestMate could not read .out files.
Once I compiled the C++ source file using the powershell terminal it created a .exe file which I then changed the path in the setting.json as Mate059 said and it showed up.
TL;DR
Mate059 gave a great answer, go into settings.json inside your .vscode folder and modify "testMate.cpp.test.executables": "filename.exe".
For me it also worked using the wildcard * instead of filename.exe but I do not suggest to do that as in that might mess up something with the .exe from the main cpp file and what not.
I'm using Parasoft C++test 9.0.
I've used "cpptestscan.exe" to create build data file(bdf), then I want to run my ruleset with "cpptestcli.exe".
When I use "New Project -> C++ Test -> Create project from a build data file" in Parasoft IDE(Eclipse based), it allows me to configure compiler setting(family, c compiler, c++ compiler and linker), and it works in IDE. But, when I create project with:
cpptestcli -bdf "%BDF_PATH%\cpptestscan.bdf" -data "%REPO_PATH%"
It creates ".metadata" and "Source(project name)" folders, and creates ".project", ".project", ".project" files in Source folder. Then, if I try to run test with:
cpptestcli -data "%REPO_PATH%" -config "%REPO_PATH%\ruleset.properties" -import "%REPO_PATH%\Source\.project" -showdetails -nobuild -report "%REPORT_PATH%\Report.html"
Because it doesn't use the proper compiler, it gives this error:
Failed checking foo.c - Coding Standards checker: error during parsing
file.
How can I tell cpptestcli.exe to use proper compiler? I can't find any option in its help document. Or is any other way to fix this problem?
there is a flag named compiler:
-compiler gcc_4_7
add it and it will use the proper compiler
First fo all, use cpptestcli -list-compilers in order to list the supported compilers. Next, use the appropriate COMPILER ID from the list in -compiler <COMPILER ID>, e.g.
cpptestcli -compiler gcc_7-64 …
I have the following project layout in Code::Blocks 13.12. I'm running as root.
Notice the file dtconfig.h is in the Headers folder.
The file is located in the same directory as the main.cpp file:
However, when I go to build I get the following error:
When I wrap the include in quotes, such as:
#include "dtconfig.h"
It works, but then I have to modify all the other headers to do the same thing. These headers are not something I have written and are part of a source project. So I don't want to go messing around with these files if I don't have to.
Is there anything I need to do/configure in the program to get this to work?
Also, I am running Ubuntu 16.04.1 LTS Mate.
You're not meant to use angle brackets (<dtconfig.h>) for your own project's code, but if you need to make them work without changing every file, then you can pass an option to the compiler telling it to use your dtSearch directory as an include directory.
I don't know whether C::B supports include directories in the GUI, but you can always fall back to passing -Ipath/to/dtSearch to GCC and Clang directly, or /I for MSVC. You can do this where C::B lets you specify additional command line options for the compiler.
I would like to have g++/gcc tell me the paths to everything non-system it is #include-ing in C++ build. Turns out, that is a tough search as Google mus-interprets it about ten different ways.
I want these filenames and paths so I can add them to the search path for Exuberant CTAGS. We have a huge project and if I use ctags on the whole thing it takes about half an hour to generate the tags file and nearly as long for the editor to do a look-up.
We use CMakeLisats to do the compiling. If there is a directive I can paste into the CMakeLists.txt, that would be extra wonderfulness.
I don't really need the default paths and filenames, Johnathan Wakely gave a good tool for that here. I think that pretty much covers the fact that this is a cross compile job. I don't need the cross-system files either.
Try gcc or g++ with the -H option (to the preprocessor part of it). From the doc:
-H
Print the name of each header file used, in addition to other normal activities. Each name is indented to show how deep in the ‘#include’ stack it is. Precompiled header files are also printed, even if they are found to be invalid; an invalid precompiled header file is printed with ‘...x’ and a valid one with ‘...!’ .
It tells you all the headers which are included. You may filter out (with grep -v or awk) those that you don't want.
You could also consider developing your GCC plugin to register these headers somewhere (e.g. in your sqlite database), perhaps inspired by this draft report, or the CHARIOT or DECODER European projects. You could also consider using, or extending, the Clang static analyzer.
In contrast to the -M options suggested in Oliver Matthews' answer, it does not tell you more (but gives all the included files).
You need to invoke g++ with the -M option.
From the manual:
Instead of outputting the result of preprocessing, output a rule
suitable for make describing the dependencies of the main source file.
The preprocessor outputs one make rule containing the object file name
for that source file, a colon, and the names of all the included
files, including those coming from -include or -imacros command line
options.
It's worth reading the manual to consider the other -M sub options (-MM and -MF in particular may be of use).
i just installed YouCompleteMe for Vim through vundle. It works, but it shows only the words contained in the current file. I want to use it to develop c++ programs, how can i configure it to show autocompletion from c++ headers file in /usr/include for example? Thanks a lot.
You need to navigate to ~/.vim/bundles/YouCompleteMe and run the installation script with --clang-completer, so do ./install.sh --clang-completer. After it finishes you should have support for C like languages.
You may also need to place let g:ycm_global_ycm_extra_conf = '~/.vim/bundle/YouCompleteMe/cpp/ycm/.ycm_extra_conf.py' in your ~/.vimrc.
I have installed with pathogen. I tried the above instructions with ./install.sh --clang-complete. After this, it did not work, and I indeed had to add the path. But it was different than in another reply here, namely
let g:ycm_global_ycm_extra_conf = '.vim/bundle/YouCompleteMe/third_party/ycmd/cpp/ycm/.ycm_extra_conf.py'
so there is an extra "third_party/ycmd" in the path.
While the suggestions here might work in the beginning, I am not sure it's the proper way to go. According to YCM developer, whenever you start a project, you need a new .ycm_extra_conf.py file
From https://valloric.github.io/YouCompleteMe/#ubuntu-linux-x64-super-quick-installation
YCM looks for a .ycm_extra_conf.py file in the directory of the opened file or in any directory above it in the hierarchy (recursively); when the file is found, it is loaded (only once!) as a Python module. YCM calls a FlagsForFile method in that module which should provide it with the information necessary to compile the current file. You can also provide a path to a global .ycm_extra_conf.py file, which will be used as a fallback. To prevent the execution of malicious code from a file you didn't write YCM will ask you once per .ycm_extra_conf.py if it is safe to load. This can be disabled and you can white-/blacklist files. See the Options section for more details.
While you might only need to modify the compile flags from the vanilla .ycm_extra_conf.py, I feel it is advisable to create a new file for every project you start.
Everything that the folks here have said is correct. I just want to add that as of 2017, the "install.sh" script is deprecated. Now, you have to use the install.py script instead by typing
./install.py --clang-completer
Also, in your .vimrc file, instead of ".vim/bundle/blahblahblah", you'll need to add a "~/" in front of the address by adding:
let g:ycm_global_ycm_extra_conf = "~/.vim/bundle/YouCompleteMe/third_party/ycmd/cpp/ycm/.ycm_extra_conf.py"
to your .vimrc file, to give it an absolute path from the Home directory so that Vim can find the ".ycm_extra_conf.py" file. Otherwise, you might experience some funny behavior.
I just wanted to add if you don't want to manually define a config file there is this neat little repository that will auto generate it. https://github.com/rdnetto/YCM-Generator