> From: "[email protected]" <[email protected]> > On 2/9/12 10:44 PM, "ext BRM" <[email protected]> wrote: >>> From: "[email protected]" > <[email protected]> >>> 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 _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
