I’d like to let you know that we’re currently working on a documentation tool as a replacement to Doxygen. It’s all still work in progress, but it’s getting to the point where it will be actually usable for projects. Compared to Doxygen, we’re trying to give some significant improvements with regard to the output and control thereof, as well as improve integration with build systems for incremental builds and distribution. Of course this is all using Clang behind the scenes. Within time, we will be open-sourcing it and will definitely need some hands to keep the project going, as well as to, for example, extend Clang’s Doxygen parser.
However, before we get to that point, we are concerned with something slightly off topic: the name, of which the tool currently does not have one. We had ClangDoc/clangdoc in mind, but we’re wondering about the general consensus of naming Clang-based tooling after Clang itself? Is there anything against that?
My impression is we usually name the tool with dash in between, like
clang-diff, clang-format, ... etc.
IMHO, clang-doxygen will be good as it remind me it tends to replace doxygen.
Thanks for the heads up, but we were aware of those options and how far we could get with Doxygen itself. It being clang-based was not really the motivation behind the project; we just started fresh and Clang was by far the best option as a parser, hence we didn't simply opt for Doxygen or a modification thereof. The same goes for DoxyPress of course, as it is a fork of Doxygen, making it not much different.
Our tool is a Doxygen replacement to us (and perhaps others eventually), but it is definitely very different in aspects such as output, configuration and with that, customization. We simply refer to Doxygen due to its seemingly dominant presence for creating c++ documentation.
Also, if all goes well, it should also be more feasible to integrate into build systems, which gives, especially us, some options for scaling more easily too. A not unwelcome addition I'd say. There's some things left to do before that, though, but we'll make sure to keep this up to date as development progresses.
That's good to know, thanks! We'd rather refrain from using Doxygen in the name though, Doxygen replacement should be read as: we are currently using Doxygen, but we will be using this instead because. It's quite a different thing altogether, the only similarities would be that we intend to parse the same style (at least).
As the developers of DoxyPress we have become extremely familiar with the code base we inherited from Doxygen two years ago. There is an option in Doxygen for clang assisted parsing using libClang, not libTooling. It is not using clang as the primary parser for C++. The maintainer uses libClang in conjunction with the lex only parser to process the names of templates when the lex parser reaches an invalid state.
DoxyPress was refactored over a year ago to use a combination of libClang to extract comments and libTooling for full C++ parsing. Neither library was sufficient on its own. We have worked with many companies who were unable to parse C++ code with Doxygen who can now use DoxyPress seamlessly.
As a great test we have generated docs for clang itself with a better html output than current Doxygen output. Doxygen was a great product at one time but each time C++ changes the maintainer has to add new lex rules by hand to the parser. Cool part about using clang is we get support for the new standard with very little effort.
A few minor points if I may. To be a replacement for Doxygen you would need to support C++ as well as other languages such as C, C#, JavaScript, Fortran, PHP, Python, etc. You will also need to support multiple outputs like HTML, CHM, RTF, Latex, QDoc, Docbook, etc. You will need to offer multiple types of diagrams, markdown syntax, and a plethora of configuration options. If your new product does all this that is wonderful.
DoxyPress is indeed a fork of Doxygen which is both a blessing and a curse. In the two plus years we have worked on DoxyPress the changes have been more than substantial. To dismiss a product simply because it is a fork misses the point. We greatly value the work which has been done on Doxygen.
DoxyPress is however a fundamentally different product from Doxygen. The internals of our application have diverged from the original product. We use modern C++, value based instead of pointer based container classes, smart pointers for memory management, and a slew of other modifications. It is faster and able to document languages and provide output which Doxygen has issues with.
The basic idea I wanted to bring up is that DoxyPress is very different internally and will continue to improve as our team has been growing and by all indications will continue to do so.
