This happens cause multilib_src_configure is for obvious reasons out of tree build and that doesn't play well with the docs contained in the tarball. It seems that einstalldocs won't cut it, cause for those to be properly installed (for - in example - devhelp), they need to go under /usr/share/gtkdoc/html/ in unversioned subdirs.
Please provide build.log and emerge --info
Created attachment 363986 [details] build log The build log won't tell you more than what I've already said: if builddir!=srcdir gtk-doc api docs from the tarball won't get installed without a stronger intervention. Just like in bug 460042.
Multilib team, how should we solve this issue? Force in-source building?
Well, first of all someone should report this upstream. I'm pretty sure gtk-doc can be convinced to work well with out-of-source builds. Then, we can either do an in-source build or copy the docs from the tarball to the build tree. Whichever fits you more.
Well, for the time being, something like the hack described in bug 460042 could work, but if gtk-doc make snippets could get such tweak, it would be even better.
(In reply to Rafał Mużyło from comment #5) > Well, for the time being, something like the hack described in bug 460042 > could work, but if gtk-doc make snippets could get such tweak, it would be > even better. I think this is not a hack, but the correct solution. In the generic case, gtk-doc's html output is generated at build time, so logically it goes in the build directory, not the source directory. So of course gtk-doc.make looks for it in $(abs_builddir), not in $(srcdir). This means that for multilib packages that provide pre-generated gtk-docs, we always need to manually copy or link the pre-generated doc directories into the correct places under the native abi build directory. Maybe we will want an eclass function for this eventually?
@multilib: well, it spread, now x11-libs/gdk-pixbuf-2.30.6-r1, x11-libs/cairo-1.12.16-r1 and x11-libs/pango-1.36.2-r1 are affected too - for the same reason. Time for a generic/template solution, ne ?
(In reply to Alexandre Rostovtsev from comment #6) [...] > Maybe we will want an eclass function for this eventually? Probably, the code that gtk+ ebuild is using is the following: # work-around gtk-doc out-of-source brokedness if multilib_is_native_abi; then ln -s "${S}"/docs/html docs/html || die fi We would need to inherit multilib-build.eclass for multilib_is_native_abi (and would probably need to check for "${S}"/docs/html presence before trying to make the link as I guess not all gnome2.eclass packages will have/need it)
(In reply to Pacho Ramos from comment #8) > (In reply to Alexandre Rostovtsev from comment #6) > [...] > > Maybe we will want an eclass function for this eventually? > > Probably, the code that gtk+ ebuild is using is the following: > # work-around gtk-doc out-of-source brokedness > if multilib_is_native_abi; then > ln -s "${S}"/docs/html docs/html || die > fi > > We would need to inherit multilib-build.eclass for multilib_is_native_abi You can't inherit that eclass without the side effect of adding abi_* flags.
The, no idea about how to handle it to prevent us from needing to add it on every ebuild using gtk-doc (they are a ton)
(In reply to Pacho Ramos from comment #8) > Probably, the code that gtk+ ebuild is using is the following: > # work-around gtk-doc out-of-source brokedness > if multilib_is_native_abi; then > ln -s "${S}"/docs/html docs/html || die > fi > ...and that code is wrong. First of all, such dir does not exist in the tarball. Second, sometimes there's more than one such dir in the tarball (like in this case) and each html dir needs to be linked.
+*glib-2.40.0-r1 (17 Jun 2014) + + 17 Jun 2014; Michał Górny <mgorny@gentoo.org> +glib-2.40.0-r1.ebuild, + -glib-2.40.0.ebuild, glib-2.38.2-r1.ebuild: + Fix gtk-doc install, bug #492544. I'm going to look for other packages having the same issue.
