When the compiler 'misbehaves' one could wrap it just as any other misbehaving application.
Depending on the build script and how it works, this can be done in one of two ways.
The ideal way, however, is to address the in the code rather than the compiler (thus the 0th way). If it is possible, this should be investigated first as it minimizes differences in build environments which can make it difficult to do a build on a different system.
Way 0 - ignore it from the compiler
This option should certainly be considered because while it makes the code slightly messier, it keeps the number of 'moving parts' in the build process lower, and thus less likely to have errors.
This has the significant advantage of that it keeps the build environment the same (compared to way 2). One wouldn't want to go and create a new Jenkins server and then have a bit of WTF time spent trying to figure out why it breaks the build to discover on the old build server, the compiler had a wrapper that the new one doesn't.
This is compiler and language dependant. MadKeithV mentioned the approach for Visual C++.
The SO question Selectively disable GCC warnings for only part of a translation unit? goes into it a bit for gcc which can be "summarized" as:
#pragma GCC diagnostic error "-Wuninitialized"
foo(a); /* error is given for this one */
#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Wuninitialized"
foo(b); /* no diagnostic for this one */
#pragma GCC diagnostic pop
foo(c); /* error is given for this one */
#pragma GCC diagnostic pop
foo(d); /* depends on command line options */
The docs for this can be seen in GCC 4.6 diagnostic pragmas
Clang uses a similar approach, though instead of
clang as specified in Ignore all warnings in a specific file using LLVM/Clang:
#pragma clang diagnostic push
#pragma clang diagnostic ignored "-Wmultichar"
char b = 'df'; // no warning.
#pragma clang diagnostic pop
One can see that this could get very confusing if compiling the same source with gcc and clang...
In Java, one has the
Way 1 - filter through a pipe
gcc args file.c | supresswarning.pl
The supresswarning.pl script would then filter the output from gcc to identify if that specific error occurred and just take it out of the output. One could also pass in the
file.c to the script and identify the line number where the annotation or macro occurs to avoid filtering real errors.
Note that this isn't quite as simple as it is shown - errors may come out on standard error rather than standard out, and the pipe would need to be adjusted appropriately. To maintain it that errors go out on the correct file handle, suppresswarning.pl would need to identify the errors and write them again to the proper file handle.
Way 2 - filter though a wrapper
If the build script doesn't like dealing with compilers in this way (think
maven style environments where it invokes the compiler itself), one could write a wrapper.
A wrapper for
javac would call itself
javac_real (the real javac that has been renamed), pass all of the options through to the real invocation and process the output and adjust return code and messages itself.
This can also be used the other way (to make it error out on warnings) if the compiler is returning warnings, and you want to fail on warnings, and the CI environment will do it if the compiler returns a non-zero exit code... but it isn't. The wrapper script could examine the output of the compiler and again, adjust the return code of the wrapper to be appropriate to the environment.