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
