[Development] RFC: The Future of QDoc

BRM bm_witness at yahoo.com
Fri Feb 10 15:42:17 CET 2012

> From: "casper.vandonderen at nokia.com" <casper.vandonderen at nokia.com>
> On 2/9/12 10:44 PM, "ext BRM" <bm_witness at yahoo.com> wrote:
>>>  From: "casper.vandonderen at nokia.com" 
> <casper.vandonderen at nokia.com>
>>> Just to add what I think to Marius' comments:
>>> 1. Doxygen would need some extra features, the major one being QML, but
>>> also being able to use index files to easily link for instance the
>>> Creator docs to the Qt docs.
>> Why would Doxygen need QML itself? Or do you mean it would need to be
>> able to process the QML/JavaScript files to get additional documentation?
> I mean that Doxygen needs to support parsing .qml files and .cpp files
> containing QML files (and that it should generate the same look of content
> for both of them).

Ok. That makes sense.

>>> 2. Even if we would use Doxygen we would still need a fork before a
>>> release, I do not think we can line up releases of Doxygen with releases
>>> of Qt.
>>>  And having a Doxygen version number like also doesn't
>>> look too great.
>> I can understand bundling a version of Doxygen with Qt in the release -
>> like many projects do for their dependencies in case those things are not
>> on the platform people are building on. E.g. Subversion bundles libneon.
>> However, I see no issue with saying that Doxygen version x.y.z is
>> required to support documentation. So why would we need to _fork_ it as
>> opposed to simply bundling a version that is known to work?
> Doxygen does not support everything we need. Maybe at some point we (the
> Qt project) will not require any new features from the documentation tool,
> then we can obviously just ship a Doxygen version that is known to work.
> What I mean is that in the beginning we'll probably have a situation
> similar to Gerrit, where we have a version deployed with the Qt project
> that is mainline with some extra patches applied (which is a fork in my
> book, or at least temporarily, until the patches are integrated in
> mainline).

Again, this makes sense. I wouldn't necessarily say it's a fork - no more so than 
a distribution packaging something with additional patches is a fork; but it's
just a matter of how the Qt community works with the Doxygen community to
get the support required then.
> That would not occur when Doxygen releases are lined up with Qt (or when
> we get lucky and Doxygen releases a version before a Qt release which has
> all our patches applied).

A matter of timing and working with the Doxygen community.
I know - it probably won't happen for a while; but we probably should have
someone reach out to Doxygen devs to get their input on what can be done, 
and what we would need to add.



More information about the Development mailing list