exhale
exhale copied to clipboard
AttributeError: 'str' object has no attribute 'get_display_string'
(Being Exhale newbie, I'm not sure where the actual problem may be, so I initially posted this as AttributeError: 'str' object has no attribute 'get_display_string' to sphinx-users list .)
I'm trying to build Boost.GIL (sphinx-exhale branch) documentation. Full logs attached below.
Doxygen and Exhale seems to run fine, as I can see this logged:
[+] Exhale: doxygen ran successfully in 11.75 seconds.
[~] Exhale: adding tree view css / javascript.
[+] Exhale: added tree view css / javascript.
[~] Exhale: parsing Doxygen XML.
[+] Exhale: finished parsing Doxygen XML in 35.71 seconds.
[~] Exhale: generating reStructuredText documents.
...
[+] Exhale: generated reStructuredText documents in 23.86 seconds.
Then, Sphinx is taking over
building [html]: targets for 4515 source files that are out of date
...
and it is failing with a very long list of warnings like
WARNING: Error when parsing function declaration.
WARNING: Duplicate explicit target name
WARNING: Duplicate ID
WARNING: Duplicate declaration.
WARNING: doxygenfunction: Unable to resolve multiple matches for function ...
Eventually failing with
Exception occurred:
File "/mnt/d/boost.wsl/libs/gil/.venv/lib/python3.6/site-packages/sphinx/domains/cpp.py", line 635, in <lambda>
return self._stringify(lambda ast: ast.get_display_string())
AttributeError: 'str' object has no attribute 'get_display_string'
I find it difficult to figure out where is the problem.
@stefanseefeld, my team mate at GIL, posted suggestion to our mailing list, https://lists.boost.org/boost-gil/2018/11/0116.php:
Just a shot in the dark: duplicate IDs sounds less like a sphinx bug, but a bug with the exhale extension, which generates content that the sphinx post-processing step then can't consume.
Is this suggestion pinpointing the issue?
I'll greatly appreciate any help.
Logs
The logs are also available at https://gist.github.com/mloskot/ad6f79b9c5fd15027467e9a55429b52et
@svenevs Thanks a lot for your suggestion to downgrade to Sphinx 1.7.9. This helped Exhale to complete generating the docs without any crashes.
I'll follow-up with some more details soon.
Ok cool thanks! I'm testing things locally right now. This project is huge by the way.
What you said about excluding the detail namespace may be necessary (at least at this time). The parser for breathe uses minidom which has memory leaks, we're switching to lxml. This one has taken a lot of time and effort because we also need to fix the testing suite x0
@svenevs (/cc @stefanseefeld)
Yes, and currently Doxygen generates docs for everything, including the detail namespace. We are going to limit that to the public definitions only, https://lists.boost.org/boost-gil/2018/11/0118.php
To follow up the chat on Gitter/Slack:
do you intend to keep the doxyfile separate or put the doxygen configs in
conf.pyFor smaller projects I suggest the latter, but for bigger projects it can be nice to keep separate.
I'd prefer to keep Doxyfile separate indeed.
When you say exclude detail namespace, do you mean entirely or just from the tree view listings? Both are possible
First, I'd exclude the detail entirely.
I think, for learning Exhale, it is a good idea to get rid of non-public definitions completely.
Once we work the configurations out, we can try to offer two types of documentations:
- User-oriented with public only
- Developer-oriented with public + internal
I'll find where breathe/exhale/Sphinx are choking and post back.
During the successful run last night, I noticed huge red log related to the C++ code parsing. There are also ~3500 warnings from Doxygen about undocumented members. Shortly, GIL's inline documentation may simply be lacking, badly formed, and we aim to clean it up gradually. Meanwhile, I can only apologies for the shitty input we feed Doxygen with :-)
BTW, I'm on 64 GB RAM and possibly I did not notice the DOM memory issues. However, I can see GIL pushes Sphinx and Exhale to the limits :)