How can we use gcovr with -g option? - code-coverage

How can we use gcovr with -g option? I've tried some commands but they all failed. I didn't get any errors but I didn't get the output that I've expected either. Documentation also does not give any examples:
http://gcovr.com/guide.html
Any ideas? Anyone used this option before?

As specified in user guide "-g" option is for directing gcovr to use existing gcov files instead of generating them again by using gcda nad gcno files.
So the only thing to understand here is gcov files should be generated first by any of the possible methods.
gcov files are files with ".gcov" extension and has the base name same as the corresponding c or c++ file. These files are annotated form of the relevant source files having symbols for signifying if the lines are executed, not executed, not a statement, branch etc. They can be generated using gcov (GNU GCC). Use this user guide to know how to do it.
Or you can use gcovr once to generate a report and use "-k" option to direct gcovr to keep all the gcov files and then again use gcovr with "-g" option to use the existing gcov files instead of regenerating them. Use the same user guide provided in the question to understand the options better.

Related

Can BUILD files have arbitrary file extensions?

I am aware that bazel accepts both BUILD and BUILD.bazel as valid filenames.
The android tools seem to also have a BUILD.tools file.
In general, does bazel have any restrictions for a BUILD file's extension? For example, could i have BUILD.generated to delineate generate BUILD files from non-generated BUILD files?
The .tools extension is part of building Bazel itself. From the perspective of Bazel, it's just any ordinary file. It gets picked up here: https://github.com/bazelbuild/bazel/blob/bbc8ed16aee07c3ba9321d58aa4c0ffc55fa2ba9/tools/android/BUILD#L197
then eventually gets processed here: https://github.com/bazelbuild/bazel/blob/c816b89a2224c3c318f1228755ef41c53975f45c/src/create_embedded_tools.py#L74
For the use case you mention, one way to go about it is to generate a .bzl file with a meaningful name that contains a macro that you can call from a BUILD or BUILD.bazel file. That way you can separate the generated rules from manually maintained rules. This is similar to how generate_workspace works: https://docs.bazel.build/versions/master/generate-workspace.html

How to keep generated source code for proto files in bazel?

I have studied https://blog.bazel.build/2017/02/27/protocol-buffers.html . The project I want to hack on is written in Go. At the moment, if I run the build command I can see the compiled binary but I don't see the *.pb.go files anywhere. I want to keep the generated *.pb.go files in the same folder where *.proto files are so that my IDE (Intellij Goland) can find and index them.
Can you please help me how to get this working? If you can show me how to do that for the github.com/cgrushko/proto_library project, I should be able to try that in my particular project.
Bazel will not output generated files (such as .pb.go) into the source tree. They go into the output directories (bazel-out/<config> or bazel-genfiles/<config>). Temporary solution might be to add those as source roots to goland. The real solution is to use https://ij.bazel.build/. It has some Go support, and the team is actively working on improving it.

how to validate the .c file has correspnding gcno or gcda files

I have a query .
Is there any way I can validate that the .c file has a corresponding .gcno and .gcda file generated.
For example :
I have a sample.c file.Now I generate the .gcno and .gcda files.
Again modify the sample.c file but I did not generate the latest gcda and gcno files for the modified .c file.
Is ther any way I can validate if the sample.c has a correspodning .gcno and gcda files genearted?
There is no specific way of doing it but the usual convention that people follow is to store the coverage data once the execution is done into a file relevantly named to execution and then remove only ".gcda" files.
This enables you to perform a different execution and generate coverage without recompiling everything.
In your case you can simply search for relevant ".gcno" file and remove that too, so that you can recompile after modification.Even if you don't delete gcno it will be over written unlike in the case of ".gcda" files which get appended.
One more thing you need to know is: if you try to generate coverage data from gcda & gcno files by gcov then it will give you a prompt saying the xyz source file is newer than the corresponding gcno file.

How to deal with .gcda and .gcno files in different directory by lcov & code coverage compare

I can generate .info files by lcov with .gcda files and .gcno files in the same directory, BUT how can I generate code coverage with .gcda files and .gcno files in defferent location?
For example,
/Users/swd/Library/Developer/Xcode/DerivedData/test1aaeyiowcssrymfbwtudrqqakuvr/Build/Intermediates/test1.build/Cov/test1.build/Objects-normal/x86_64/AppDelegate.gcno
/Volumes/Data/test1/test1/AppDelegate.gcda
I tried --add-tracefile but failed, and output 'lcov: ERROR: no valid records found in trace file'
My second question is whether lcov have some command to compare my old version coverage html to my new one, so that I can find the difference.
Any ideas? Thanks
Well few things needs to be cleared first to avoid confusion for other people.
.gcno and .gcda are never generated on different location for a single object file. (At least that's what I know from my experience)
When a source file is compiled either by using an automated builder or by manual commands, it generates .gcno files and .o files at the same location. And afterwards when you perform any kind of execution the object files trigger coverage generation functions and generate .gcda files at the same location as '.gcno' and object files.
And if they are generated for different .gcno files then they can not be used together anyway.
This can happen if the environment variable GCOV_PREFIX is set. See here
The suggested solution is to release the .gcno files to $GCOV_PREFIX by doing something like
rsync -acv --filter='+ */' --filter='+ *.gcno' --filter='- *' <directory-containing-object-files> $GCOV_PREFIX

Perform separate compilation of Latex documents

When compiling latex documents the compiler emits a lot of "object" files. This clutters the directories I'm working on and it difficults the use of VCS like SVN. When I work with C++ code I have separate directories for the code and the objects, I can run make on the source directory but the .o files go to the build directory.
Is there a proper way to perform this separate compilation with Latex documents? Can it be done by using Makefiles or by passing options to the latex compiler?
Thanks
You can use:
pdflatex --output-directory=tmp file.tex
and all the files will be stored in the folder tmp (pdf included).
Because this is not an optimal solution, I made my own tool, pydflatex, that compiles the LaTeX source by stashing away the auxilliary files (using the trick above), and brings the pdf back to the current directory, so after compiling you only have file.tex and file.pdf in your directory. This plays very well with version control.
I can't help much with LaTeX (having last user it seriously 20 years ago;-), but for Subversion, you should read up on the svn:ignore property -- it makes it easy to ignore files with extensions you do not want to version (object files, bytecode files as Python can often put in the same directory as the sources, backup files some text editors use, &c).
Latex generates the temporary files in the directory where the main document is located. If you want the contents to be placed in a different location, try with a main file like below.
\documentclass{article}
\input{src/maindocument.tex}
Using this method, you could maintain a directory structure like below
/
main.tex
/src
maindocument.tex
Two options, besides the above.
Use Lyx: it looks after the separate files. I think it copies the Latex file over to its own private directory and runs latex on it. In any case, nothing is created in the current directory.
Use a makefile or one of the special Latex make programs, and have your regular targets run make clean.

Resources