[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 1.7.6.2-qt-SHA1 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.

$0.02

Ben




More information about the Development mailing list