Jay --
Rearranging slightly...
On Thu, Feb 28, 2013 at 10:22 AM, Meyer, Jay (MPAU) <
jay.me...@smiths-medical.com> wrote:
> This mailing list is so responsive usually!
>
> I can only conclude that the question is too stupid to bear a response or
> that there is no answer.
>
Well, if you're a bit miffed that this one was missed while another got
traction, I'm not sure there's much to say.
As it turns out, I didn't join these lists until this week anyway, so I
don't know what might have been going on during that time.
One way that you might get better (any?) responses is to offer a list of
what you tried. Remember the golden questions of bug reports (and support
requests): what are you trying to do? how did you try to do it? what did
you expect? what did you actually get?
> On Feb 8, I wrote:****
>
> ** **
>
> I do not seem to be able to get doxygen to parse files that are within the
> scanned directories if the include looks like:****
>
> #include <cstdlib>****
>
> And the filename is: cstdlib****
>
> ** **
>
> How can I pull these files in?
>
There's also some ambiguity here. Are you saying that doxygen refused to
work with any file in the scanned directories, if it included files from
the standard library, or if it included files without extensions? That'd
be odd, and it's not what I see in my use here. (Although, Doxygen is so
configurable that "in my use" is a pretty big qualifier.)
Or are you asking that, since you had a scanned (and parsed) file that did
"#include <cstdlib>", you want the "cstdlib" file to be included in your
documentation? That'd be a little odd to me, since the "cstdlib" file is a
part of the C++ and C standard libraries: do you really intend to have
documentation for the standard libraries be generated as a part of the
documentation for your project?
If you just want to see links to those files, but not details, then that's
the default behavior of Doxygen (at least in my experience). In fact, one
of the reasons I got involved recently was that I was *removing* #include
directives that brought in the standard (and boost) files, as they were
cluttering the graphs for my project.
Or do you want "stubs" for standard includes, so you can get a graph of all
of your files that include a particular standard library component? That's
a potentially interesting use, and one that I don't immediately see how to
implement. Some jiggering with "show all included files" and "show even if
undocumented" might get that to work, although it runs afoul of the first
question again.
Maybe the right answer is to develop the concept of an "external
dependencies" category; with a clear-enough definition, it might be
something that could be added to the tool in a straightforward fashion.
> Did find one way to do it - explicitly name each file that has no
> extension in the input.
>
> Maybe that's what I need to do?
>
If you automate your document generation, you could perhaps do a quick
"grep" through your source base, looking for standard headers that are
included; you could then add them to the doxygen config file before the
run.
------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_feb
_______________________________________________
Doxygen-users mailing list
Doxygen-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/doxygen-users
