-
Bug
-
Resolution: Fixed
-
P4
-
9
-
None
-
b119
-
windows
When using the RC tool on Windows, we also run CL with the same arguments to generate dependencies on included files. In some cases, extra include directories are provided in the RC_FLAGS, using the flag -i (lower case). This flag works for the RC tool, but not for CL, which requires -I (upper case). The upper case version works for RC as well so we should switch to using upper case.
Another problem uncovered by this is that NativeCompilation.gmk isn't handling this failure well. It calls CL through the ExecuteWithLog macro. This macro will copy the log to the failure-logs dir if the command returns non zero. Because of the above problem, the command returns non zero. NativeCompilation.gmk ignores this so the build continues. If the build then fails for any other reason, the failure report will find these failure logs and fool the user into thinking this was the cause of the build failure.
I propose to fix this by changing NativeCompilation.gmk to not ignore the return code of CL and let the output of CL through, but filtered the same way as when we do normal compilation. Then the build will actually fail if CL fails here so there is no discrepancy between failure-logs and the actual failure. To make this work, we must also ensure that no bad arguments reach CL here.
Another problem uncovered by this is that NativeCompilation.gmk isn't handling this failure well. It calls CL through the ExecuteWithLog macro. This macro will copy the log to the failure-logs dir if the command returns non zero. Because of the above problem, the command returns non zero. NativeCompilation.gmk ignores this so the build continues. If the build then fails for any other reason, the failure report will find these failure logs and fool the user into thinking this was the cause of the build failure.
I propose to fix this by changing NativeCompilation.gmk to not ignore the return code of CL and let the output of CL through, but filtered the same way as when we do normal compilation. Then the build will actually fail if CL fails here so there is no discrepancy between failure-logs and the actual failure. To make this work, we must also ensure that no bad arguments reach CL here.