#47901: cmake @3.2.2_0+docs+gui: build documentation in Qt help/Assistant format --------------------------+------------------------- Reporter: rjvbertin@… | Owner: michaelld@… Type: enhancement | Status: new Priority: Normal | Milestone: Component: ports | Version: Resolution: | Keywords: haspatch Port: cmake | --------------------------+------------------------- Comment (by rjvbertin@…): Replying to [comment:1 larryv@…]:
… should produce more documentation than this…
No, I didn't add anything to the +docs description, but there is not "more" documentation that is built. The same documentation is simply compiled in an additional format, which isn't the same thing. It could use that description, but lacking that I don't see why anyone would be confused. Except by the fact that getting the Qt help requires a specific python variant, but that could also go in the variant description.
A more obvious approach would be to add a variant for the Qt help that required `+gui +docs +python34`. Another possibility would be to ditch the Python variants and have `+docs` use Python 3.4 Sphinx and build the Qt help unconditionally.
I personally find that the port already has enough variants and variants of variants, and I think Michael's intention with that is to allow choice instead of enforcing choice on users (Qt4 or Qt5, python2.7 or python3.4). The only possible interest of a specific Qt help variant that I can see is to install that help format *instead* of the HTML version. Compiling the help in Qt format requires Qt, which is why I made it a side-effect of +gui+docs. Anyway, my expectation here was mostly to remind Michael of the possibility to provide the help in Qt format, he's capable enough to see how to implement it exactly. -- Ticket URL: <https://trac.macports.org/ticket/47901#comment:2> MacPorts <https://www.macports.org/> Ports system for OS X