Geoff Worboys writes:
> I've been playing around with this. The problem seems to be > that I'm specifying TAGFILES pointing to the tags that > include the vectorObj base class that's installed in > /usr/include. In other words, this Doxyfile, where the warning > is emitted from, has a TAGFILES setting pointing to a tagfile > that was generated from the source that installed the vectorObj > header file in /usr/include.That could be significant information for anyone trying to offer suggestions ... don't you think? ;-) > If I take out the link to the tagfile, the weird warnings for > <unknown>:1 are not emitted. But then I have a slew of others, > of course, for all my other \refs to the documentation for the > external classes, that are now pointing nowhere. I've done very little with trying to merge help files, so I'm not really in a position to offer much here ... but: >> Is load(const fd &fdRef) actually being overridden in snorkle >> or not? And if so, is the override documented? > > Nope, not overridden. This seems significant. The only reason I can think of for doxygen to be complaining about no documentation would be if it thought this member should be documented with regard to the project being generated. It may be worth a look at how your
The project where this warning is emitted, project B, does not use any of the class methods that are listed in the warnings. Project A, where the template class is defined and whose tagfile project B reads, does use those class methods.
The template class parameter, the "constraint" part of vectorObj<constraint>, comes from project B, which declares a class that's derived from vectorObj<constraint>, and the warnings are referencing the "constraint" class.
What's basically happening is that doxygen thinks that the instantiation, vectorObj<constraint> is a discrete class, then complains that it can't find the documentation for any of its class methods. The only reason that doxygen knows about what's in vectorObj is because it reads the tagfile from the project where the vectorObj template gets declared. I think that's what's happening, but it doesn't seem to be happening for everything that's imported from the tagfile, only for the class that gets instantiated as a superclass.
using this member (and compare to others for which you don't get any complaint) to see if there is anything odd. I mean, why is doxygen even looking for documentation for a member that should (presumably) only appear inside the code? To answer my own question: I'm guessing it could be looking so it can create links inside the included header files. Could the messages be coming only from members of the external library that you are using in inline functions in the headers?
The methods are being used in inline methods, but in project A's headers, which doxygen shouldn't be seeing, when it's processing project B's source, where the warnings come from, and which doesn't even use those methods.
Not that knowing this necessarily helps very much. But to see if this is the case you could try setting VERBATIM_HEADERS to no and see if the messages goes away. You may also want to check your SOURCE_BROWSER and related options.
They're already NO.
pgpOz9Yp8O9Dc.pgp
Description: PGP signature
------------------------------------------------------------------------------ How ServiceNow helps IT people transform IT departments: 1. A cloud service to automate IT design, transition and operations 2. Dashboards that offer high-level views of enterprise services 3. A single system of record for all IT processes http://p.sf.net/sfu/servicenow-d2d-j
_______________________________________________ Doxygen-users mailing list Doxygen-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/doxygen-users
