Ebuild file not support compile with locales another than EN. Doxygen generate warning: "Output language Russian not supported! Using English instead.". Doxygen compiled without language support. But LINGUAS set correctly. I see in emerge output that USE linguas_ru is set. Reproducible: Always Steps to Reproduce: 1.LINGUAS=ru emerge doxygen 2.Set in Doxyfile: OUTPUT_LANGUAGE = Russian 3.Run doxygen Actual Results: in stderr output: warning: Output language Russian not supported! Using English instead. Expected Results: Run without this warning. In build time, generated file lang_cfg.h has wrong define: ./work/doxygen-1.8.10_build/generated_src/lang_cfg.h:#define LANG_ru Right content of lang_cfg.h is #define LANG_RU. It use in language.cpp for preproccesing #ifdef LANG_RU to include translate_ru.h. For repair current situation I am change in ebuild: ... get_langs() { ... case ${lingua} in ... ru) lingua=RU ;; ... } But problem in other language this change not repair. Please change ebuild file by correctly method for repair subj problem.
Seems to me to be a peculiar case of case-sensitivity ..
Thanks for the response. Analyzing this problem, I noticed that this applies to the entire localization, not only Russian. Russian language was given as an example. Use capitalize value in LINGUAS don't solved the problem.
I test LINGUAS="it de fr". Doxygen generate warning: warning: Output language French not supported! Using English instead. warning: Output language German not supported! Using English instead. warning: Output language Italian not supported! Using English instead.
Please verify that 1.811-r2 supports your languages. Note: I have removed the LINGUAS use expand alltogether - all supported translator units are just compiled in unconditionally (this is the configuration default). commit af672b80bbf952b557244f39f8f77c3fa9c3c7f3 Author: Matthias Maier <tamiko@gentoo.org> Date: Tue Jun 14 23:18:27 2016 -0500 app-doc/doxygen: remove LINGUAS use expand, bug #584782 doxygen has language support in form of quite a number of "translator" units. We had the habit of fine-tuning the translator units that are actually built via the LINGUAS use expand mechanism. But this is a broken approach due to the following reasons: - "translator" units are lightweight header files that are built into doxygen during compilation. No external dependencies are required. - Traditionally, the LINGUAS variable is used for packages to determine runtime language support (especially for GUI programs, etc) that usually requires additional packages to be installed - i.e., LINGUAS controls the languages supported in CLI and GUI applications. doxygen's support for translator units does *not* fit into this scheme at all. - Not all translator units have a LINGUAS equivalent (!!) - Hand selecting supported LINGUAS is a maintenance burden. Therefore, I just got rid of it and install *all supported* "translator" unconditionally. Package-Manager: portage-2.2.28
It's work. You method is good idea! Thank you.
