https://blogs.gentoo.org/ago/2020/07/04/gentoo-tinderbox/ Issue: dev-cpp/nlohmann_json-3.10.5 fails to compile. Discovered on: amd64 (internal ref: ci) NOTE: If you think this is a GCC-11 related issue, please block bug 732706.
Created attachment 761715 [details] build.log build log and emerge --info
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=7b00b0d50adbead8ba39f90f90fe27d0b8a4aac6 commit 7b00b0d50adbead8ba39f90f90fe27d0b8a4aac6 Author: Sam James <sam@gentoo.org> AuthorDate: 2022-01-11 04:32:45 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2022-01-11 04:33:17 +0000 dev-cpp/nlohmann_json: disable docs in 3.10.5 I tried to package the needed bits but they end up needing network at runtime, it seems. Closes: https://bugs.gentoo.org/830862 Signed-off-by: Sam James <sam@gentoo.org> dev-cpp/nlohmann_json/nlohmann_json-3.10.5.ebuild | 14 ++++++-------- 1 file changed, 6 insertions(+), 8 deletions(-)
yeah, I was trying to figure that out as well. It seems they dropped support for doxygen to produce html files and require serving the files (locally?) from within a python venv. I'm not sure what the point of that change was, but it seems this approach here works best to resolve the issue in gentoo.
(In reply to Amel Hodzic from comment #3) > yeah, I was trying to figure that out as well. It seems they dropped > support for doxygen to produce html files and require serving the files > (locally?) from within a python venv. > > I'm not sure what the point of that change was, but it seems this approach > here works best to resolve the issue in gentoo. I was even trying to figure out the mkdocs stuff but it turns out it needs an extension which.. needs a server to render the diagrams and it defaults to a remote one! I feel like even if we could get it working, the audience for this is very very small or non-existent.. but if someone wants it & has a patch, we can discuss it of course! Thanks for looking into it too. I don't like giving up like this but sometimes it's the best option.
Indeed. Alternative suggestion was to build docs for older version, by checking out e.g. tag 3.10.4. If needed later on, may be a possibility. But, in my opinion, it's not worth potentially introducing new issues--at least for now.