Doxygen 1.8.4 uses libclang to improve parsing

Hi All,

I'm pleased to announce that as of version 1.8.4 doxygen can optionally use libclang to
provide a more accurate source browsing experience, and better syntax highlighting,
cross referencing, and call graphs.

To enable this feature use
./configure --with-libclang

and then set CLANG_ASSISTED_PARSING to YES in doxygen's configuration file.
Additional compiler options can be passed via CLANG_OPTIONS.

You can download doxygen from: Doxygen: Downloads
or get the code directly from GitHub: GitHub - doxygen/doxygen: Official doxygen git repository

Feedback is welcomed.

Regards,
  Dimitri

Great news! How does it work: How does doxygen get hold of the compiler
flags that it needs to pass to clang?

(This is the hardest thing I've found with any clang-based tooling.)

--Dave.

Hi David,

I'm pleased to announce that as of version 1.8.4 doxygen can optionally use libclang to
provide a more accurate source browsing experience, and better syntax highlighting,
cross referencing, and call graphs.

Great news! How does it work: How does doxygen get hold of the compiler
flags that it needs to pass to clang?

(This is the hardest thing I've found with any clang-based tooling.)

Doxygen adds -I for all directories that are part of the input.
It detects the language (C++/ObjC/ObjC++) based on file extension and adds the proper -x option.
For other compiler options it relies on the user to pass them via the CLANG_OPTIONS tag, so it
is not perfect.

Doxygen does show the compiler warnings and errors so you can see if some option is still missing.

Regards,
  Dimitri

We designed a whole system to solve this problem. Some documentation:

http://clang.llvm.org/docs/JSONCompilationDatabase.html#json-compilation-database-format-specification
http://clang.llvm.org/docs/LibTooling.html#writing-a-standalone-tool

It would be best to re-use this work so that all of the tools use the same
platform for communicating with build systems.

Thanks; I'm aware of the JSON compilation database. It's still a little
bit complicated if you're not using CMake. :slight_smile:

I've tried to document the various approaches here (it's the README for
my toy tool, "clang-ctags"):
https://github.com/drothlis/clang-ctags#compilation-command-line

Though it would certainly be awesome if Doxygen supported the
compilation database... :slight_smile:

Interesting! I'll look into it.

Regards,
  Dimitri

And that context brings up the need for having a .h file mapping for the
compilation database again. Daniel had the idea that we might get the 99%
case by simply looking for files with the same base name to compile (and
look whether the header is "obviously" included from there), but it still
seems, um, dirty.

The other way would be to somehow mark the include dump files that
compilers produce to be input to the compilation database, so we can build
up the reverse graph from there, but that would always require enough of a
build (but that's already true for generated files).

/me is still looking for good ideas here...

Cheers,
/Manuel

One header file can be included from C, C++, Objective-C code (in same project) or with different preprocessor state. It's better to infer header file options from sources where it was included.

Also doxygen doesn't need to scan headers directly, they will be scanned by indexing API when procesing source files. XCode collects diagnostic for headers from indexing without guessing header options, too. But probably it guesses header options from inclusions in *.cpp before highlighting header, opened in editor.

Of course, platform-specific headers still suffer.

20.05.2013 23:57, Manuel Klimek пишет: