On Thu, Jun 7, 2012 at 7:10 AM, Logan Bell <[email protected]> wrote: > It would seem that having a "CC_capture_warnings" would probably be a > useful general purpose function to have.
That approach is plausible: compile twice capturing compiler warnings and fail if the warnings differ. It's not a route we typically want to take because we'd like to verify that compiler features actually *work* -- but we're backed into a corner here. > I would also volunteer to try to implement the technical details for this > function, unless there are any objections creating such a method? This would be a nice feature to have. However, coding it up would actually take a fair amount of refactoring, as the assumption that we throw away compiler output is pretty deeply baked in. It might be quicker to try enabling warnings as errors. This is done with -Werror on GCC and Clang, and with /WX on MSVC. Since this is likely to be a rarely used feature, I'd propose a CC_warnings_as_errors(int enabled) setter that controls a static variable within Compiler.c. If that static variable is non-zero, then we tack on the extra flag when generating the compiler command within CC_compile_exe() and CC_compile_obj(). Then in SymbolVisibility.c, we'd enable that setting for only as long as necessary. > Or, perhaps the reason it doesn't exist is because it's not trivial for all > of the various compilers we support? It's doable but not trivial, both because of the compiler and the shell. MSVC writes its boilerplate to stderr, so I'm not sure the approach is generalizable to all compilers. And redirection syntax is different under cmd.exe than under Unix shells. Marvin Humphrey
