Anyone know if it's possible to build a VS2003 project from the command line without showing any warnings? We've got a heap of VS2003 projects that get built by TSFBuild as part of our platform build and the warnings are just noise in the build log file.
I have looked at the parameters by running devenv.com /help and nothing there seems relevant. VS2010 has a build output verbosity setting but I couldn't find one for VS2003. I am also looking to see if it can be configured through the project file.
Seems like you're building your projects using MSBuild. If so, you can try suppress the warnings by setting the WarningLevel property as suggested here. Or you can choose the console logger to not show the warning and error summary, then output them to seperate files as provided here:
/consoleloggerparameters:parameters
NoSummary: Hides the error and warning summary displayed at the end
of a build.
/fileloggerparameters:
You can use up to ten file loggers by
following the parameter with a digit
identifying the logger. For example,
to generate separate log files for
warnings and errors, use -
/flp1:logfile=errors.txt;errorsonly
/flp2:logfile=warnings.txt;warningsonly
Related
I would like to make my main branch TFS build definitions to treat warnings as errors so that the build fails when the projects are not error free. Since I do not want to activate "treat error as warning" in all project as a default, my first idea was to add a powershell script to my main build definition that substitues false with true in the line <TreatWarningsAsErrors>...</TreatWarningsAsErrors> in all csproj files it finds (something along the line of this). Is there any better/straighter way via some option as part of the build definition settings?
In the build definition specify /p:TreatWarningsAsErrors=True in the MSBuild argument field.
This will override any setting from the csproj files.
Unfortunately, there is no this kind of settings as part of the build definition.
However, you could be able to return warnings and errors from your powershell script using logging commands. With using task.logissue type=error you could fail the build task and then fail the build.
More details you could take a look at this similar question: Is it possible to raise and display build warnings from build steps using TFS 2015
An "Errors exist in the active configuration of project X. Proceed with launch?" dialog appears while debugging code in Eclipse. Hitting the "Proceed" button results in successful debugging. There are no apparent errors with the launch configuration. A similar Run Configuration does not generate the error.
This is caused by an invalid path somewhere in your Eclipse project settings. There are a couple common sources for this kind of error.
You're working on a shared (version controlled, copied, etc) project where someone has hardcoded a path that doesn't exist on your machine, or uses an environment variable that you've not set.
Sometimes, you can find the offending path by looking at the full list of Error messages. If not, look in your project file.
The Discovery Options in your project properties has 'Automate discovery of paths and symbols' enabled - but the process is generating an error.
If you're using a version of Eclipse that warns you this option is deprecated, uncheck the option to disable it and fix any includes in 'Preprocessor Include Paths' instead. If not. . .try it anyway.
Depending on your path changes, restart Eclipse and try again.
It starts the executable that was built last before you broke the build. That executable will be older then your source files. The reason you were able to debug is because your line numbers did not change for the code you've debugged - e.g. you may try break in main then introduce a compilation error and move main a couple lines below - the debug will highlight the wrong lines when it stops.
With Vuforia's ImageTargets sample application, I tried using OpenGL ES 1.1 by setting USE_OPENGL_ES_1_1 to true in jni/Android.mk and uncommenting and changing the corresponding line in AndroidManifest.xml (). After converting the project so that it has a C++ perspective and associating ndk-build and the proper include directories, I could successfully run the application on my Android device.
However, the problem is that once I open up jni/ImageTargets.cpp, I get several errors from Eclipse, all from places where OpenGL ES 2.0 code would execute, the first one being:
Description Resource Path Location Type Symbol 'vertexHandle' could
not be resolved ImageTargets.cpp /ImageTargets/jni line 402 Semantic
Error
Sure enough, vertexHandle is defined at the top of the ImageTargets.cpp, inside the "#ifdef USE_OPENGL_ES_2_0" block. Because USE_OPENGL_ES_2_0 is not defined (per Android.mk), the code should be able to compile successfully, and sure enough, ndk-build does not report any problems. So it seems that only Eclipse reports the problems and when I run the project, Eclipse says, "Your project contains error(s), please fix them before running your application." And thus, I cannot run my application anymore. In a sense, it's kind of strange that this never occurred until I opened ImageTargets.cpp and Eclipse "discovered" the errors.
The best work-around I've found so far is to just delete or comment out those lines (that should not be causing problems because USE_OPENGL_ES_2_0 is not supposed to be defined)... Is there a better way to deal with this problem? Did I miss a setting in Eclipse that should solve this?
I've found a solution: go to the project properties -> C/C++ Build -> Discovery Options -> Check "Automate discovery of paths and symbols"
I'm trying to use Eclipse CDT's headlessbuild feature for integrating Eclipse with TeamCity. I use a command line call to build my projects as descriped in this question. If there is a compilation error, a message box pops up saying "Java was started but returned exit code=1". I'd rather not have this message but get the return code so I can process it further in my script. Is there any way to do this?
Thanks!
You can suppress the popup and redirect output to be included with your script:
Add "--launcher.suppressErrors" to your command line arguments for eclipse
The error needs to be tracked down in the GUI from what I can tell, because the headless mode doesn't support very good error reporting from sub-tasks yet.
From there I used output from the GUI-based build to narrow down why my project failed to build.
Sources:
http://dev.eclipse.org/mhonarc/lists/cdt-dev/msg15343.html
http://www.eclipse.org/forums/index.php?t=msg&goto=481938&S=c88d71260a7d130eebdccb8f2e5537f2
http://www.eclipse.org/forums/index.php?t=msg&goto=481938&S=c88d71260a7d130eebdccb8f2e5537f2
https://bugs.eclipse.org/bugs/show_bug.cgi?id=209080#c21
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