It would be nice to have Qt documentation packaged. Since most people would prefer to use qch format, qttools module (or at least qhelpgenerator) is needed. But the last one depends on qt-gui and qt-help: $ ldd /usr/lib/qt5/bin/qhelpgenerator | grep Qt5 libQt5Help.so.5 => /usr/lib64/libQt5Help.so.5 (0x00007fe246399000) libQt5Gui.so.5 => /usr/lib64/libQt5Gui.so.5 (0x00007fe245dcb000) libQt5Core.so.5 => /lib64/libQt5Core.so.5 (0x00007fe2457fd000) libQt5Widgets.so.5 => /usr/lib64/libQt5Widgets.so.5 (0x00007fe245025000) libQt5CLucene.so.5 => /usr/lib64/libQt5CLucene.so.5 (0x00007fe244d0d000) libQt5Sql.so.5 => /usr/lib64/libQt5Sql.so.5 (0x00007fe244ace000) libQt5Network.so.5 => /usr/lib64/libQt5Network.so.5 (0x00007fe2447a3000) Moreover, Qt5Help is the part of qt-tools. So it is not trivial to add doc use flag to ebuilds. Thus I propose to add a new set of qt-*-doc ebuilds. Thes ebuils depend on global qdoc configs, whic can be installed by qt-core. I will attach a separate eclass qt5-build-doc for simplicity, but it can be easily integrated into qt5-build. Reproducible: Always
Created attachment 338736 [details, diff] Changes to qt-core to install global docs
Created attachment 338738 [details] Eclass for docs
Created attachment 338740 [details] qt-base-doc-5.0.1.ebuild Ebuild to install "base" module docs. All other modules, except webkit, have the same ebuilds
Created attachment 338742 [details] qt-webkit-doc-5.0.1.ebuild Due to some error in dependencies handling, `make docs` for webkit fails. Additional make invocations ni src_compile() create missing files for docs target
Proposed ebuilds list should include a -doc ebuild for every qt module, except those are in qtbase repository, and additional qt-doc-doc ebuild with ugly name to install docs from doc module.
Created attachment 338744 [details] qt5-build-doc.eclass cleaned up eclass
I'd prefer having a doc USE flag for the various modules, instead of adding separate qt*-doc packages. Even if this implies circular deps when USE=doc is enabled.
(In reply to comment #4) > Created attachment 338742 [details] > qt-webkit-doc-5.0.1.ebuild > > Due to some error in dependencies handling, `make docs` for webkit fails. > Additional make invocations ni src_compile() create missing files for docs > target These issues need to be reported upstream I guess.
(In reply to comment #7) > I'd prefer having a doc USE flag for the various modules, instead of adding > separate qt*-doc packages. Even if this implies circular deps when USE=doc > is enabled. Sorry, I can not understand how this can be implemented in modularized qt build. We need qt-widgets and qt-help for doc compilation. So how docs for qt-core, for instance, can be installed? Maybe we can have separate packages and PDEPEND on them instead under doc use? This will automatically install docs, but build them separately
(In reply to comment #9) And what is even worse, that complete qt-tools package needs qt-widgets and qt-webkit. Surely, we can split it into qt-helpgenerator and all the rest, but this is illogical. We can split it into qhelpgenerator, assistant, designer, linguist, help, pixeltool, qdbus, qdbusviewer, qcollectiongenerator, qhelpconverter (10 in total). I believe this is to many of packages. Comparing to that hell, separate doc packages do not look to bad, don't they?
(In reply to comment #8) > These issues need to be reported upstream I guess. https://bugreports.qt-project.org/browse/QTBUG-29673
Created attachment 338772 [details, diff] qt5-build.eclass.diff Change qt5-build.eclass to: 1. Add doc use flag to packages; 2. Add PDEPEND on ${PN}-doc package if doc use enabled 3. Handle compilation of doc packages (just merge qt5-build-doc.eclass with qt5-build.eclass).
I don't know if a USE=doc is feasible, I haven't investigated doc building in qt5 yet, I'm just saying what the best approach is in my opinion. (In reply to comment #10) > And what is even worse, that complete qt-tools package needs qt-widgets and > qt-webkit. Surely, we can split it into qt-helpgenerator and all the rest, > but this is illogical. We can split it into qhelpgenerator, assistant, > designer, linguist, help, pixeltool, qdbus, qdbusviewer, > qcollectiongenerator, qhelpconverter (10 in total). I believe this is to > many of packages. Comparing to that hell, separate doc packages do not look > to bad, don't they? That is more or less what is going to happen in fact. assistant, designer and linguist *must* be split, for other reasons that I won't detail here. Probably qdbus{,viewer} and pixeltool too. All doc-related tools can instead go in a qtdoctools package or something like that.
I'm absolutely sharing your view that installing documentation for each package by the package itself is nice and clean. But, IMO, Qt buildsystem is so unhandy, that it will result in much more pain than profit. I repeat: 1. qhelpgenerator needs widgets and help libraries. 2. One can not compile documentation for just qt-core or qt-gui, but only for qtbase as a whole (well, maybe one can patch makefiles, or invoke internal make targets, but does it worth the goal?). So, if, say, qt-core installs docs, then it needs to compile qhelpgenerator, which needs widgets, and you can not move it to PDEPEND. So this is impossible, right? Then which package from qtbase repo will install docs? Looks like a separate package is needed anyway. If so, why not do in the same way for all packages? BTW, Qt's recomendations for docs compilation is to unpack all modules and run `make docs` :)
Davide, I've looked at some of qt modules. It seems that prepare_docs target exists in all of them. After this target, one can cd into the required directory and make docs qch_docs. So, it is possible to have docs compiled for each subdir of the module. If I change qt5-build to behave in this way, and split qt-help-tools from qt-tools, will you accept it?
(In reply to comment #15) Yeah, sounds reasonable, thanks! :)
Created attachment 338932 [details, diff] qt5-build.eclass.diff
Created attachment 338934 [details] qt-base-doc-5.0.1.ebuild
Created attachment 338936 [details] qt-tools-doc-5.0.1.ebuild
Created attachment 338938 [details] qt-help-5.0.1.ebuild
Created attachment 338940 [details] qt-helpgenerator-5.0.1.ebuild
Created attachment 338942 [details] qt-assistant-5.0.1.ebuild
It is not obvious what package from splitted qttools module can install help library documentation (and qt-help can no do this --- qhelpgenerator is not compiled yet), I decided to make qt-tools-doc separate package. Each module, except qtbase and qttools installs documentation by itself.
Why qt-assistant as RDEPEND? Are the changes to ./configure arguments really necessary?
(In reply to comment #24) > Why qt-assistant as RDEPEND? Typo > > Are the changes to ./configure arguments really necessary? It would be confusing to have use flags c++11, debug, and prefix for documentation packages. Well, maybe prefix should be applicable... So if -doc ebuilds do not have thsese use flags, they can not use checks of their values. qt-base-doc compiles (I was unable to fix this) qdoc and QtBootstrap.a. This is the only place where config flags become inconsistent between installed libraries and copmiling ones.
Maybe c++11 flag for doc package also makes sence: documentation can be hided under #ifdef
I just (also) created qt5 doc ebuilds, without looking at bugzilla first.. I came across the same circular dependency: For creating qt-core docs, one needs qt-assistant, which of course depends on qt-core. So I created a separate qt-core-doc ebuild, which only installs the docs for qt-core. I added a 'doc' useflag to qt5-build.eclass, which enables installing docs, except for qt-core. For qt-core, the 'doc' flag only enables installing the 'global' doc definitions. For the other packages qt-assistant depends on, creating a separate doc ebuild is probably also necessary, or you should somehow extract the qhelpgenerator. I also created an ebuild for the qt reference documentation (qtdoc package). It looks like you already have everything covered, however, if you're interested in my ebuilds, please let me know.
Although your doc ebuilds look very sound, I found a small glitch: Since you only install qch docs, you don't install the global docs from qtbase anywhere. Any docs besides qtbase-doc won't install, as the package needs the .qdocconf files from doc/global. Furtunately the fix is simple. Change the src_install of qtbase-doc-5.0.1.ebuild to: src_install() { qt5_install_docs (cd ${QT5_BUILD_DIR} ; emake INSTALL_ROOT=${D} install_global_docs) } Furtermore, all packages that have the 'doc' useflag and qttools-doc will have to depend on qtbase-doc.
(In reply to comment #28) No, I do the same as you do. See https://457028.bugs.gentoo.org/attachment.cgi?id=338736 and changes in eclass (install_global_docs function)
(In reply to comment #29) Argh, after carefully processing the other attachments I somehow completely missed that one. Perhaps because I added it to qtbase-doc, and not qtcore. In my current install I merged the qthelp and qthelpgenerator ebuilds. The qthelp ebuild installs all help tools: src/assistant/{clucene,help,qcollectiongenerator,qhelpconverter,qhelpgenerator}, which is everything except the assistant. The qtassistant ebuild only installs src/assistant/assistant. In the qtassistant ebuild I now only have to fix the destination dir in src/assistant/assistant/assistant.pro. I can omit the other fixes, so the ebuild becomes cleaner. Maybe you'll want to do the same. Do you or Davide already have any idea when we can expect these updates in the qt overlay?
(In reply to comment #30) > Do you or Davide already have any idea when we can expect these updates in > the qt overlay? Thanks a lot to both you and Eugene for the continuous efforts on this. I need to carefully review all the diffs and the new ebuilds, especially wrt any changes that might have happened to doc building for Qt 5.1. Unfortunately I'm quite busy right now, sorry... I hope to start working on this around mid-April.
Hey! I's mid-April already ;)
Indeed! Qt5 is not that important for every day use now, but for porting and testing it is essential to have docs and developer tools. Thus, as for me, Qt5 ebuilds in the current state serve mainly ebuilds maintainers (by the fact of their existance so they can be used as dependencies) than present-day users, who are most probably those who want to develop with Qt5.
It looks like that in 5.1 qdoc itself is no longer a bootstrapped tool, it now depends on QtCore and QtXml, which means yet another circular dependency...
Davide, please, do whatever you want: I, for example, would be happy with any number of PDEPNDs in these packages, just release them, please! Separate qtdoccompiler package will not do much harm, I believe. In any case it will be better to have _any_ doc packages, than having custom builds of Qt (or own ebuilds) in the system.
Created attachment 359364 [details, diff] qt5-build.eclass.diff updated qt5-build.eclass that knows about separate qdoc
Created attachment 359366 [details, diff] qtcore-5.1.1.ebuild.diff seems like compilation of docs is not optional anymore
Created attachment 359368 [details] qdoc-5.1.1.ebuild
Created attachment 359370 [details] qtbase-doc-5.1.1.ebuild
Created attachment 359372 [details] qhelpgenerator-5.1.1.ebuild
Created attachment 359374 [details] qthelp-5.1.1.ebuild
Created attachment 359376 [details] qttools-doc-5.1.1.ebuild
Created attachment 359378 [details] assistant-5.1.1.ebuild
(In reply to Eugene Shalygin from comment #37) > Created attachment 359366 [details, diff] [details, diff] > qtcore-5.1.1.ebuild.diff > > seems like compilation of docs is not optional anymore Mmm can you elaborate please?
> > seems like compilation of docs is not optional anymore > > Mmm can you elaborate please? Sorry, my fault. Had to write "compilation of global docs". With version 5.0 we were passing "-make docs" to configure to install these files, but with 5.1 configure does not know about 'docs' part and these files are installed without any switches.
Updated ebuilds for 5.2.0_beta1 are in an overlay (fork of the qt overlay) here: https://github.com/evsh/gentoo-qt5-with-docs Layman cfg is here: https://github.com/evsh/gentoo-qt5-with-docs/blob/docs/layman-repo.xml
Hello. What is a status of this issue? There is a fork of gentoo qt overlay https://github.com/evsh/gentoo-qt5-with-docs (by Eugene Shalygin), what kind of work needs to be done to merge it to upstream? Is there any hope to have qt docs enabled in qt overlay in sane time?
(In reply to Alexander Akulich from comment #47) > What is a status of this issue? There is a fork of gentoo qt overlay > https://github.com/evsh/gentoo-qt5-with-docs (by Eugene Shalygin), what kind > of work needs to be done to merge it to upstream? Is there any hope to have > qt docs enabled in qt overlay in sane time? There has been zero progress on this issue. I also consider it low priority, therefore, given my very limited time, I don't think I'll work on it anytime soon, certainly not before qt5 is out of package.mask
Created attachment 389272 [details, diff] qtcore-5.3.2.ebuild.patch Updated qtcore ebuild, so it will now install global docs unconditionally. 'global' directory is 660K big, so Davide proposed to get rid of use flag. This (and only this) patch must be applied to resolve bug 479638.
(In reply to Paweł Stankowski from comment #49) > Updated qtcore ebuild, so it will now install global docs unconditionally. > 'global' directory is 660K big, so Davide proposed to get rid of use flag. `du -h` says 392K here. > > This (and only this) patch must be applied to resolve bug 479638. Thanks. I committed a different but equivalent patch to qt5-build.eclass, with an additional fix for prefix. https://github.com/gentoo/qt/commit/0c7c3aec2835675afd7b1fbcdea4fde9edd25bbb
(In reply to Davide Pesavento from comment #50) > Thanks. I committed a different but equivalent patch to qt5-build.eclass, > with an additional fix for prefix. > > https://github.com/gentoo/qt/commit/0c7c3aec2835675afd7b1fbcdea4fde9edd25bbb Now in gx86 too.
Created attachment 394556 [details] qtdocumentation-5.4.0.ebuild Instead of building documentation for every Qt module, let's install the full pre-build one from download.qt.io.
Created attachment 396932 [details] qtdocumentation-5.4.0.ebuild Correct source directory
Created attachment 397476 [details] qtdocumentation-5.4.1.ebuild
Eugene's latest ebuild seems fine to me. Qt team - can we get this in the tree?
[Don't change the priority please, this still has low priority for the qt team.] This bug was initially about *building* the docs from source. Do we all agree that installing prebuilt docs is fine? How about "qt-docs" as package name instead?
Pre-built package has a big advantage over per-package builds: cross-module links are not disabled. Given the fact that the size of the whole docs package is only 174 MiB, I would prefer the pre-built one.
Prebuilt is fine with me too.
Created attachment 398648 [details] qtdocumentation-5.4.1.ebuild Apparently it needs p7zip to unpack sources
I've cleaned things up quite a bit and put it in my overlay: http://git.zx2c4.com/portage/tree/dev-qt/qtdocumentation/
+*qtdocumentation-5.4.1 (14 Mar 2015) + + 14 Mar 2015; Jason A. Donenfeld <zx2c4@gentoo.org> +metadata.xml, + +qtdocumentation-5.4.1.ebuild: + Qt documentation import
(In reply to Jason A. Donenfeld from comment #61) > +*qtdocumentation-5.4.1 (14 Mar 2015) > + > + 14 Mar 2015; Jason A. Donenfeld <zx2c4@gentoo.org> +metadata.xml, > + +qtdocumentation-5.4.1.ebuild: > + Qt documentation import Has anyone in the qt team acked this? Or even reviewed it? If not, please revert your commit.
Yes, yes! Please revert and wait two more years!
(In reply to Davide Pesavento from comment #62) > (In reply to Jason A. Donenfeld from comment #61) > > +*qtdocumentation-5.4.1 (14 Mar 2015) > > + > > + 14 Mar 2015; Jason A. Donenfeld <zx2c4@gentoo.org> +metadata.xml, > > + +qtdocumentation-5.4.1.ebuild: > > + Qt documentation import > > Has anyone in the qt team acked this? Or even reviewed it? If not, please > revert your commit. Reviewed and ack'ed on IRC by kensington and me.
Why was my suggestion for $PN ignored (comment #56)? I'm particularly pressing for the $PN thing because "qt${foo}" without hyphen should be reserved for qt modules, and this is not an official module.
It doesn't make a difference to me. Talk about it with the qt team, and if they also like that idea, go ahead and rename the package.
(In reply to Davide Pesavento from comment #65) > Why was my suggestion for $PN ignored (comment #56)? I'm particularly > pressing for the $PN thing because "qt${foo}" without hyphen should be > reserved for qt modules, and this is not an official module. I thought it was the official documentation. Anyway, I have moved it.
