dev-libs/efl: use docs.eclass for building docs

[AndrewAmmerlaan]

As requested by @juippis , an example on how to use
the new docs.eclass with doxygen

See-Also: #16366
Package-Manager: Portage-3.0.11, Repoman-3.0.2
Signed-off-by: Andrew Ammerlaan andrewammerlaan@riseup.net

[gentoo-repo-qa-bot]

Pull request CI report

Report generated at: 2020-12-06 11:39 UTC
Newest commit scanned: a2c6903
Status: ✅ good

There are existing issues already. Please look into the report to make sure none of them affect the packages in question:
https://qa-reports.gentoo.org/output/gentoo-ci/6bb99265a5/output.html

[juippis]

I'm getting,

 * ERROR: dev-libs/efl-1.25.1-r10::testworld failed (compile phase):
 *   doxygen_compile: doc/Doxyfile not found, DOCS_DIR=doc or DOCS_CONFIG_NAME=Doxyfile wrong
 * 
 * Call stack:
 *     ebuild.sh, line  125:  Called src_compile
 *   environment, line 2908:  Called docs_compile
 *   environment, line 1329:  Called doxygen_compile
 *   environment, line 1339:  Called die
 * The specific snippet of code:
 *       [[ -f ${doxyfile} ]] || die "${FUNCNAME}: ${doxyfile} not found, DOCS_DIR=${DOCS_DIR} or DOCS_CONFIG_NAME=${DOCS_CONFIG_NAME} wrong";

with this applied, while the ::gentoo one installs fine.

 >:  equery f efl | grep "/html" | wc -l
654

I kind of have a vague memory of doxygen failing as-is, but doxygen . working for some reason. It's probably related?

[juippis]

Other feedback: Using the eclass looks really simple. Kind of surprised to see nothing is needed in src_install, but I do get and see the logic with: HTML_DOCS+=( "${DOCS_OUTDIR}/." ) in docs_compile.

[AndrewAmmerlaan]

I'm getting,

 * ERROR: dev-libs/efl-1.25.1-r10::testworld failed (compile phase):
 *   doxygen_compile: doc/Doxyfile not found, DOCS_DIR=doc or DOCS_CONFIG_NAME=Doxyfile wrong
 * 
 * Call stack:
 *     ebuild.sh, line  125:  Called src_compile
 *   environment, line 2908:  Called docs_compile
 *   environment, line 1329:  Called doxygen_compile
 *   environment, line 1339:  Called die
 * The specific snippet of code:
 *       [[ -f ${doxyfile} ]] || die "${FUNCNAME}: ${doxyfile} not found, DOCS_DIR=${DOCS_DIR} or DOCS_CONFIG_NAME=${DOCS_CONFIG_NAME} wrong";

with this applied, while the ::gentoo one installs fine.

 >:  equery f efl | grep "/html" | wc -l
654

I kind of have a vague memory of doxygen failing as-is, but doxygen . working for some reason. It's probably related?

Oopsie, my bad, I was editing the -r10 version and emerging the -r2 version, I'll look into it

[AndrewAmmerlaan]

I kind of have a vague memory of doxygen failing as-is, but doxygen . working for some reason. It's probably related?

@juippis So turns out there is a meson.build file in the doc directory that is supposed to create Doxyfile from Doxyfile.in. I could not get that to work so I just do the necessary edits in src_prepare, and now docs compilation works just fine.

So turns out the ebuild was not actually compiling the docs correctly before, because by calling doxygen . the config file is bypassed and the generated docs are not complete. It should be complete now, in any case the generation of the docs takes significantly longer now indicating that it is now doing things that it was not doing before.

Ideally we would get the automatic generation of the Doxyfile from the Doxyfile.in working, but I lack the knowledge and experience with meson.build files to get it working.

[gentoo-repo-qa-bot]

Pull request CI report

Report generated at: 2020-12-06 15:29 UTC
Newest commit scanned: 36c1cbe
Status: ✅ good

There are existing issues already. Please look into the report to make sure none of them affect the packages in question:
https://qa-reports.gentoo.org/output/gentoo-ci/6d907989c9/output.html

[gentoo-repo-qa-bot]

Pull request CI report

Report generated at: 2020-12-06 15:49 UTC
Newest commit scanned: fcfdeb4
Status: ✅ good

There are existing issues already. Please look into the report to make sure none of them affect the packages in question:
https://qa-reports.gentoo.org/output/gentoo-ci/f10349c808/output.html

[juippis]

Heh, my only experience with doxygen and it was wrong. No wonder I had a weird feeling about it. Thanks for looking in! Left a question about DOCS_DIR regarding future reviews.

Also you're welcome to port any maintainer-needed / proxy-maint packages to use this eclass if you want, and they'll get reviewed. Can't promise that for packages with other maintainers.

[juippis]

Does the ${S} need to get specified now with doxygen? Or is this specific to efl?

[AndrewAmmerlaan]

For sphinx you can get away with using a relative path. For doxygen and mkdocs DOCS_OUTDIR has to be a absolute path because those docbuilders have to be run in the directory where the config file is, which means that if DOCS_DIR is not equal to S (the default) the docbuilder and einstalldocs are not run from the same directory which will cause einstalldocs to fail because it can't find the directory specified in HTML_DOCS. Because DOCS_OUTDIR is set relative to DOCS_DIR this means that DOCS_DIR has to be an absolute path.

This morning I thought of a solution that will allow the eclass to be used with relative paths in DOCS_DIR (changing the default DOCS_OUTDIR from DOCS_DIR/_build/html to S/_build/html). That way DOCS_OUTDIR is an absolute path by default, and it is not longer strictly necessary for DOCS_DIR to be an absolute path as well.