I am having some problems running my build.cake file, but I can't immediately see what the problem is. Is there a way to enable diagnostic verbosity, so I can get more information about what is going on, and how to fix the problem?
Yes, you can easily enable diagnostic verbosity in Cake. This allows you to see much more information about the Cake execution, including the actual commands, and arguments, that are passed to the numerous underlying tools that Cake can call on your behalf. This can be especially useful if you are finding issues when calling tools, and things aren't working as expected. By getting the command that is being called, you can test this outwith Cake to make sure it is working as expected.
How you enable diagnostic verbosity really depends on how you are calling the cake.exe.
Directly
cake.exe --verbosity=diagnostic
Via PowerShell Bootstrapper
.\build.ps1 -Verbosity Diagnostic
Via Bash Bootstrapper
.\build.sh --verbosity=diagnostic
NOTE: Another option might be to debug your build.cake file. This can be done by passing --debug into cake.exe, and then attaching the debugger. More information on this can be found here.
In addition, you can also pass other options for the Verbosity flag. These are described in detail here. These options are:
Minimal
Normal
Quiet
Verbose
Related
I have C/C++ application and I am trying to run cov-build and getting a warning “ NO FILES EMITTED”. Can you please help me as we doing the POC on Coverity for static code analysis.
C:\Users\Master\bamboo-agent-home\xml-data\build-dir\DEC-L11PROJ-JOB1>cov-build --dir cov-int IarBuild.exe MainApplication\EWARM\L11_P4_uC1.ewp -build *
Coverity Build Capture (64-bit) version 2019.03 on Windows 10 Enterprise, 64-bit (build 18362)
Internal version numbers: 2c0f9c8cf4 p-pacific1-push-35439.872
IAR Command Line Build Utility V8.4.8.6680
Copyright 2002-2020 IAR Systems AB.
Total number of errors: 0
Total number of warnings: 0
[WARNING] No files were emitted. This may be due to a problem with your configuration
or because no files were actually compiled by your build command.
Please make sure you have configured the compilers actually used in the compilation.
For more details, please look at:
C:/Users/Master/bamboo-agent-home/xml-data/build-dir/DEC-L11PROJ-JOB1/cov-int/build-log.txt
First, if you are involved in a pre-sales Proof of Concept (POC), then there should be a Coverity Sales Engineer assigned to help with the POC. That person's role includes providing instructions and information similar to what I'll offer below, as well as answering technical questions such as yours. There may have been a miscommunication somewhere. Get in contact with the Sales Engineer, as they will be able to help more reliably and completely than I can.
Now, what's going on? The primary purpose of cov-build is to watch the build process for invocations of compilers, and when one is found, compile the same code using the Coverity compiler (called cov-emit). But in order to recognize a compiler, cov-build needs to know its command line name, what kind of compiler it is, where its include files are stored, etc. This is accomplished by a helper tool called cov-configure that must be run before cov-build. If cov-configure has not been run, then no compiler invocations will be recognized, which appears to be the case for you, as indicated by "No files were emitted".
Synopsys has a page called CLI Integration Cheat sheet that gives these commands for use with IAR:
cov-configure --comptype iar:arm --compiler iccarm --template
cov-build --dir <intermediate directory> "c:\Program Files (x86)\IAR Systems\Embedded Workbench 6.5\common\bin\IarBuild.exe" sample_project.ewp -build Debug -log all
I can't personally vouch for these commands (I don't have IAR, nor access to the Coverity tools anymore; I'm a former employee), but something like that will be needed. Again, your assigned Sales Engineer should be able to help.
Finally, for new Coverity users, I recommend using the cov-wizard tool. cov-wizard is a graphical front-end to the command line tools, and has help text explaining the concepts and procedures, along with a convenient interface for performing them. There are several steps even after cov-build, and cov-wizard will walk you through all of them. Its final screen shows exactly what command lines it used in case you want to script them.
I have just started using Eclipse CDT and would like to know why there are two run configurations such as Debug and Release.
Could I use this this to improve my workflow in any way? The manuals for CDT just mention that there are two default configurations, but never mention why.
Thank you for your answers.
Not specifically to Eclipse, but for all software and web development you'll encounter these two configurations.
You use Debug to test your application. You will probably generate debug symbols to step through your code, and it will probably avoid some optimizations. The purpose is to facilitate diagnosing issues.
Then, Release configuration is the one you want to use to publish or deploy your application. It could apply optimizations.
Also, if you make want to connect to different servers, or name files differently, or even execute different path codes depending if you are testing locally or if the final user is executing what you made.
Another example is Logging and Tracing, in Debug mode you may want to enable things to print to console or write to a file/log. But in Release you'll want to avoid them if it reduces the performance
I'm trying to debug a program written using Go inside eclipse. I can set and hit breakpoints pretty consistently, but I cannot view the contents of my variables. When I start debugging the program, I always get the following error on my console.
warning: File "/usr/local/go/src/pkg/runtime/runtime-gdb.py" auto-loading has been declined by your `auto-load safe-path' set to "$debugdir:$datadir/auto-load".
To enable execution of this file add
add-auto-load-safe-path /usr/local/go/src/pkg/runtime/runtime-gdb.py
line to your configuration file "/home/johnlawrie/.gdbinit".
To completely disable this security protection add
set auto-load safe-path /
line to your configuration file "/home/johnlawrie/.gdbinit".
For more information about this security protection see the
"Auto-loading safe path" section in the GDB manual. E.g., run from the shell:
info "(gdb)Auto-loading safe path"
Thinking that the problem might be due to the error message, I put the entry into my .gdbinit file as instructed. However, I get the same message every time I run as if I did nothing at all. This is the contents of my /home/johnlawrie/.gdbinit file
add-auto-load-safe-path /usr/local/go/src/pkg/runtime/runtime-gdb.py
Any ideas what I need to do to make this change take effect? I have tried logged off and back in.
Thanks,
John Lawrie
It did learn what was happening. When gdb is started from Eclipse/CDT, it is started with option -nx, which means it doesn't load .gdbinit in the home directory.
I was able to get this to work by creating a .gdbinit file as a peer to the src, bin, and pkg directories in my workspace and adding the following line to it
set auto-load safe-path /usr/local/go/
It should be add-auto-load-safe-path /usr/local/go/src/pkg/, not the path to the script.
Also keep in mind that gdb doesn't really work with Go, specially v1.3.
From http://golang.org/doc/gdb:
GDB does not understand Go programs well. The stack management,
threading, and runtime contain aspects that differ enough from the
execution model GDB expects that they can confuse the debugger, even
when the program is compiled with gccgo. As a consequence, although
GDB can be useful in some situations, it is not a reliable debugger
for Go programs, particularly heavily concurrent ones. Moreover, it is
not a priority for the Go project to address these issues, which are
difficult. In short, the instructions below should be taken only as a
guide to how to use GDB when it works, not as a guarantee of success.
When doing remote debugging, some commands affect only the local debugger (the debugger on which the command is typed). Examples are:
.wtitle
.cls
.browse
.cmdtree
At the moment these are all looking like UI related commands. Are there more commands that are only executed on the local debugger?
My research effort:
I was googling for a list, but maybe the search terms are too common or I don't get them right.
I have also tried finding a reference in WinDbg help (.hh) itself. But the fact is not even documented on the affected commands I found so far.
I am aware that this is asking for a favorite external tools or reference. So if you really think this is off-topic, then vote for close.
All debugger processing, including all extension execution, is done in the core debugger process. So 99+% of commands all need to go to the debugger engine (the initial debugger instance)
The only commands that run only on the remote debugger are indeed a few UI related commands.
I will call out one pair of commands that is interesting on this topic which is the mostly commonly used remote debugger:
.srcpath sets the "source code path" in the debugger engine. This is where the debugger engine will get source information from if it's needed - for example, if a debugger extension wants to get to the source code.
.lsrcpath (l - for local) sets the "source code path" in the remote debugger. This path will be used in windbg (and cdb\kd also) to pull up source files in the UI.
Still not a complete list, but many commands that are not scriptable (MSDN) are affected:
.lscrfix // works on remote client only
.lsrcpath // works on remote client only
.open
.write_cmd_hist // writes local history only
.beep
.cls
.hh
.remote // Does not work in WinDbg anyway
However, the following ones from the list seem to work:
.idle_cmd
.restart
Regarding .write_cmd_hist: If you want to keep all commands executed during the debug session, it seems good to open a log file (.logopen) at the beginning of the session.
How would I suppress all warnings (or at least as many as possible since those prefixed with MSB cannot be suppressed How to suppress specific MSBuild warning)?
msbuild /clp:ErrorsOnly
/consoleloggerparameters:
Parameters to console logger. (Short form: /clp)
The available parameters are:
PerformanceSummary--Show time spent in tasks, targets
and projects.
Summary--Show error and warning summary at the end.
NoSummary--Don't show error and warning summary at the
end.
**ErrorsOnly--Show only errors.**
WarningsOnly--Show only warnings.
NoItemAndPropertyList--Don't show list of items and
properties at the start of each project build.
ShowCommandLine--Show TaskCommandLineEvent messages
ShowTimestamp--Display the Timestamp as a prefix to any
message.
ShowEventId--Show eventId for started events, finished
events, and messages
ForceNoAlign--Does not align the text to the size of
the console buffer
DisableMPLogging-- Disable the multiprocessor
logging style of output when running in
non-multiprocessor mode.
EnableMPLogging--Enable the multiprocessor logging
style even when running in non-multiprocessor
mode. This logging style is on by default.
Verbosity--overrides the /verbosity setting for this
logger.
The best way is to fix the issues that are causing the warnings.
If you must ignore the warnings (e.g. you have inherited a project with so many that you can't see the wood for the trees), you could try changing the WarningLevel property, http://msdn.microsoft.com/en-us/library/13b90fz7.aspx
If you would like to suppress MSB3270 only then you can set in project file just
<PropertyGroup>
<ResolveAssemblyWarnOrErrorOnTargetArchitectureMismatch>
None
</ResolveAssemblyWarnOrErrorOnTargetArchitectureMismatch>
</PropertyGroup>
In Jenkins
Happened upon this Googling "how to suppress MSBuild warnings in Jenkins"
So much noise like the following in our console output, couldn't find the meat
Missing XML comment for publicly visible type or member
Inherited Jenkins on a Windows server
Manage Jenkins > Global Tool Configuration > MSBuild
Add /clp:ErrorsOnly to the Default parameters