Alan W. Irwin wrote:
My first interpretation was "that" referred to graphviz, but in fact the
file was produced at cmake time, and it was a simple matter to process
it by
hand using the "dot" command-line tool (even though I had never heard of
that tool or graphviz before). "gv" has errors for both the ps and pdf
results, but I think that is because the latest gv is extra careful about
non-standard ps and pdf files. xpdf could understand the pdf output, but I
have to say the result is black with dependency lines to a frightening
extent. I can send the pdf file to Brad and/or you off-list if either of
you
is interested in being frightened by the PLplot dependencies as well. :-)
Seriously, I am fairly impressed with the graphviz result, and adding in
the file depends would add a lot of value to the result.
If your "that" refers to file depends instead of graphviz, I don't
understand your comment since surely file depend information is
available at
cmake time?
No file level depends are done mostly a build time. This is a
performance issue. Some generators like VS IDE do file level depends by
themselves. With the makefiles cmake computes the depends, but at build
time not cmake time. The custom command stuff output input is known at
cmake time, and maybe enough for what you want. But if you have a file
foo.c with #include <foo.h>, cmake does not know that foo.c depends on
foo.h until build time.
-Bill
_______________________________________________
CMake mailing list
[email protected]
http://www.cmake.org/mailman/listinfo/cmake
