On Mon, Feb 21, 2011 at 6:38 PM, Bill Hoffman <bill.hoff...@kitware.com> wrote: > On 2/21/2011 12:16 PM, j s wrote: > >> >> LD_PRELOAD isn't that bad of a hack, actually. Intercepting open(), >> read(), and possibly mmap() should cover most cases. >> >> >> So >> cl.exe /showincludes >> >> doesn't work? According to this, it is available. >> >> http://www.conifersystems.com/2008/10/09/dependencies-from-showincludes/ >> >> > > Although slower that what we have. I did write a depend system once that > used cl.exe. It basically ran the cpp over the code (cl -E) , and grepped > out all the #line information. It has the advantage of not using an system > tricks, and all of the compilers we support can be made to print out #line > numbers with a cpp output. We don't have any free cycles to work on this at > Kitware right now. >
Just an idea, but wouldn't it be possible to make the dependency scanner used by CMake customizable. I mean one may want to use its own dependency scanner, instead of the built-in one, for whatever reason. I see at least two use cases: 1/ To work around #if 0 bug in cmake dependency scanner http://www.vtk.org/Wiki/CMake_FAQ#CMake_dependency_scanner 2/ Some project generate code and may have a higher level point of view regarding files dependencies and could generate dependency files faster. This may also helps to add support for build-system like tup in CMake. -- Nicolas Desprès _______________________________________________ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake