This is a problem that I've faced multiple times before. I download a project and type make, but it won't compile because warnings are being treated as errors. I want to override this and I don't care about the risks. I also don't want to hunt through the source code to look for every flag. So how do I get projects to compile using make without warnings being treated as errors on the command line?
Related
I am hacking around a problem we've created for ourselves. What I would like to do is log a warning in our TFS builds for any code that is instantiating a specific class. I don't want a run time warning (I've got one in place already), I want a build time warning that ProjectX is using BadClass.cs. The idea being it will give us an additional place to see things that need to be fixed once our hack is no longer needed.
So something like this:
public class BadClass
{}
public class OkClass
{}
public class MyBadService
{
var a = new BadClass(); <-- Logs a warning to the build output
}
public class MyOkService
{
var a = new OkClass(); <-- Does not log a warning
}
Edit:
I do not like the idea of using Obsolete; its a misnomer. We've already got code with Obsolete attributes and this would get lost in the noise. I don't want a generic warning that I can't control the message for. I want bright neon signs with klaxons firing and a thousand exclamation points in the message. Basically everything I can do short of failing the build. I'm using the #warning precompiler directive right now and its mostly doing what I want but it requires a human to remember to add the warning. I'm looking for something more automagic. I've seen third party libraries do stuff like this so I know its possible.
Why not just use the Obsolete attribute? It can generate a build warning for you:
https://learn.microsoft.com/en-us/dotnet/api/system.obsoleteattribute?view=netframework-4.8
You can even make it emit an error too if you want.
The answer could be negative I think.
It seems that you use or call msbuild.exe to build your C# projects. But as far as I know, MSBuild in fact calls csc.exe to build C# projects in build time.
So actually what you want is logging a warning when the compiler compile the C# code if it recognize somewhere in your code uses the BadClass in build time.
If you have the source code of BadClass in the same solution, add a project reference format to the xx.csproj which contains BadClass, and set a #warning in the BadClass it may generate the warning in build time.
But I think the scenario you're in is something like: You developed one Assembly and distribute it to your user, so you want it generates a warning when the user calls one BadClass in your assembly and builds his own project to remind him of taking care when using this bad class. If so, this is impossible for msbuild AFAIK. If I misunderstand anything, feel free to know me know :)
Update:
As Daniel and Johnson said, ObsoleteAttribute is enough to do this. Though no valid way to generate warnings from msbuild aspect directly, but msbuild will call C# compiler during build process, so generates a compiler warning can output to build output window.
I am getting some mysterious compiler type related errors in my ts code. I have another thread addressing them.
But I know there will be no adverse reactions to my code, so I would like to force it to compile and make my js files anyway so I can do some run-time debugging.
I have seen a comment or two about the project compiling despite some build errors. How do I do that? If I use the command line compiler it seems to do this, but apparently I am spoiled VS programmer who wants a to build in one step, not two.
I have VS2013 and TS 1.5.
Thanks, Brad
How do I do that? If I use the command line compiler it seems to do this, but apparently I am spoiled VS programmer who wants a to build in one step, not two.
Make sure that in your csproj you have noEmitOnError set to false.
I find that Swift is quick to mark down changes i make as compiler errors in the side panel, and then when i compile, it decides i am right after all. Is Swift just pessimistic about my code?
Can I get the compiler to wait for me to finish the line before declaring it wrong?
There is nothing pessimistic. Xcode uses the same tool - the compiler - to get the errors. However, it usually compiles only one file, using cached compiled objects for the other files. It also doesn't invoke the compiler after every change in your code, so errors that are already fixed can stay there in the side panel.
Building the project fully forces Xcode to refresh the cache and get the current list of errors from the compiler. I do agree that Xcode has many imperfections and this is one of them. When you can't find an error, just rebuild the project.
Note that IDEs for other languages often rebuild the project automatically to solve such problems. This is currently not an option in Swift because it would take too much time.
Is there a way to enforce gcc to ignore errors which result from C++11's override?
Explanation: I want to enable C++11 in a program. Unfortunately it misused some functions and macros from a library causing many marked override, but does not override errors. So I want to disable the error, just to check if there are more issues and then replace the errors step by step.
I checked the -W options, but they handle warings only. This is a real error.
As a hack you can use -Doverride= on the command line. This will make it so GCC does not see override.
I find it difficult sometimes to locate errors/warnings in large projects upon make-ing (gnu). How do I segregate the errors/warnings from the usual compilation messages when the error does not stop the build process from going any further? A wrapper shell script could pick and display whatever I want, but before fleshing out one I thought of asking about the alternatives.
Thanks.
In theory, make -s will suppress the "routine" output of the build process, leaving you with only the errors and warnings. Also in theory, make will stop as soon as it encounters an error.
If either of those is not true for the project(s) you're working with, that's probably due to poorly written makefiles. So fixing the makefiles is one alternative.
To help make sense of verbose builds, some simple highlighting as provided by colorgcc can go a long way. IDEs like eclipse or even emacs can also helpfully pick out the error messages in the build output.
Also, it might be helpful to note that warning and error messages are usually written to stderr, while everything else goes to stdout. So it might be useful to simply discard stdout like so: make >/dev/null.