On 01/28/2015 09:06 AM, Brian Smith wrote: > it seemed wrong to me to inherit the C/C++ include directories for > assembly language compilations, so I removed it.
I don't think it is getting the C/C++ flags. It's getting the preprocessor flags. Anyway, we agree to skip this hunk. > Good point. Again, BoringSSL's assembly language code doesn't use > ".include" so I'm not sure what is correct. However, both the nasm > documentation and the yasm documentation say that "-M" should be used > to generate makefile dependencies. > > IMO, it is a good idea to fix this bug by committing a variant of the > second hunk, and then file a new bug about correctly getting > dependencies from nasm/yasm. If you agree, I'm happy to send an > updated patch that removes the first hunk and that changes the deptype > line in the second hunk to something else. In that case, what should I > change the deptype line to? The original issue could have been worded to explain that nasm/yasm dependencies are not handled correctly, so I'd like to treat it that way. If these tools have the -M flag then a "deptype = gcc" code path should work. The usingMSVC boolean should be updated to be false for lang != C|CXX|RC so that the "else" code path is taken. Then CMAKE_DEPFILE_FLAGS_<LANG> should be added to the platform modules for these toolchains. Thanks, -Brad -- 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/mailman/listinfo/cmake-developers
