On 02/08/17 10:45, PICCA Frederic-Emmanuel wrote:
First, that's very speculative. Second, that's upstream's problem.# If extensions (or modules to document with autodoc) are in another directory, # add these directories to sys.path here. If the directory is relative to the # documentation root, use os.path.abspath to make it absolute, like shown here. # # import os # import sys # sys.path.insert(0, os.path.abspath('.')) You need to customize the sys.path in order to find the extensions.
The snippet you quoted is not specific to extension modules but to the use of the autodoc feature, which requires the modules to be in the PYTHONPATH. The `sys.path.insert` hack is just here so that you don't have to specify PYTHONPATH yourself when running the upstream Makefile.
This path can change depending on the setup.py build options so this is not reliable.
I don't understand how setup.py / build options are affecting the Sphinx documentation. You are supposed to either call the generator manually via sphinx-build (which the style guide recommends), or using the upstream Makefile (which upstream often does).
As far as reliability is concerned, my reference here is upstream. If upstream can produce the docs, then I should be able to do it too. And they don't have pybuild for that.
Why? All you need is *one* occurrence of the extension modules somewhere in the PYTHONPATH in order to generate the docs. Chances are that's how upstream generates them.Because by experience I find issue in the build system and the python code when building the doc for multiple interpreter (python2/python3 differences...)
Why would you build the docs for each supported Python version, considering you'll end up shipping only one instance of the generated HTML? I am probably missing something here.
You might as well generate the docs just once with the default Python 2 or Python 3 interpreter, the same way you would do without extension modules, no?
Pardon my insistence, but I really fail to understand what issues you are referring to.
Found a total of 643 reverse build-depend(s) for python-all-dev. not that smallHow is the ratio over all the Python packages? I suspect very small.Found a total of 1968 reverse build-depend(s) for python-all. not that small 32 % ;)
More than I expected, indeed.And amongst these 643 packages, how many have such large build times that the overhead of an additional inplace call would be considered prohibitive, I wonder?
Besides, the docs will typically be processed by arch-all builders (provided you use -indep targets), so arch-any builds won't even feel that overhead, right?
I could be wrong though.