I'm seeing some build problems show up on cdash from some of my builds that use ninja.
The error that shows up on cdash is: ninja: error: GetFileAttributesEx(c:\Program Files (x86)\Mcl : Command line warning D9025 : overriding ): The filename, directory name, or volume label syntax is incorrect. When building a set of 3rd party libraries, I simply add /w to the compile flags to suppress any warnings from them. I could go back to that and modify how I'm suppressing them to take out the default /W3 to avoid this "command line warning D9025" I'm getting. But, it doesn't show up on cdash anyway, and it uncovers another problem that should probably be fixed anyway. With some help from the ninja mailing list, they pointed me in the direction of cmcldeps included in CMake. I have now confirmed that a ".d" file generated by cmcldeps contains a line: ....hdf5-1.8.10/src/CMakeFiles/hdf5.dir/H5Pdcpl.c.obj.d:c:\\Program\ Files\ (x86)\\Mcl\ :\ Command\ line\ warning\ D9025\ :\ overriding\ '\\W3'\ with\ '\\W0' \ cmcldeps calls cl.exe with the additional argument of /showIncludes and it parses the output to make a list of includes. When I call "cl.exe /nologo /showIncludes ... /W3 ... /w .... " manualy and redirect it, I noticed the D9025 warning is printed to stderr and everything else to stdout. And when printed to the console, or when both the stderr and stdout are redirected to the same file, I always get the D9025 warning on the first line. I also want to mention that compile errors go to stdout, not stderr. But, it seems that when cmcldeps calls cmSystemTools::RunSingleCommand(), the stderr and stdout are merged inconsistently. I'm guessing this inconsistency is why I get the D9025 warning on a line that starts with "Note: including file: ..." I'm not sure if cmcldeps can be changed to ignore stderr, or if kwsysProcess needs fixed to alternately read stderr/stdout in the order the child process printed to them. I imagine the latter might be possible if the same HANDLE was given to the STARTUPINFO's hStdError and hStdOutput, if we aren't already doing that. I can't quickly tell what ProcessWin32.c is doing in that respect. Also, ninja appears to have some of its own dependency tracking capabilities. Is there any reason not to switch away from cmcldeps and use ninja's deps=msvc? So, does anyone have any tips on where to go next? Thanks, Clint
-- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
