Ok, If I replace
'{interpreter} setup.py build_man'
by
'env; setup.py build_man'
I get this
HOME=/home/picca
PYTHONPATH=/home/picca/Debian/silx/silx/.pybuild/pythonX.Y_2.7/build
but If I read the code of
def create_pydistutils_cfg(func):
"""distutils doesn't have sane command-line API
So I am sltill investigating
with some debug output, I can see this the first build part gives
dh_auto_build -- --after-build '{interpreter} setup.py build_man'
pybuild --build -i python{version} -p 2.7 --after-build "{interpreter}
setup.py build_man"
D: pybuild pybuild:474: version: 2.2
Hello Piotr,
I am struggling, with the build system.
I will speak about this solution
> | override_dh_auto_build:
> | dh_auto_build -- --after-build '{interpreter} setup.py build_man'
the code instrumented of the BuildMan is this one
class BuildMan(Command):
"""Command to build man p
> 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.
I just sa
> First, that's very speculative. Second, that's upstream's problem.
> The upstream Makefile and conf.py are likely generated by Sphinx itself
> via sphinx-quickstart. Did your upstream tinker with them that much that
> they cannot be trusted?
No this is just that does not fit well with extension
> PYTHONPATH=. sphinx-build -N -b html
> One can also use the sphinx-generated Makefile if available:
> PYTHONPATH=$(CURDIR) $(MAKE) -C html
> Both are simple one-liners and do not rely on pybuild.
Yes it works but this is fragile since the organisation of the module can
change in the sourc
> At the end of the day, it is just a matter of providing an appropriate
> PYTHONPATH, regardless of whether pybuild is used or not.
Yes but to avoid the multiplications of way to provide this PYTHONPATH.
Is it possible to have the recommended way which works for modules and
extensions.
once ag
> Perhaps the LibraryStyleGuide should be updated to reflect on this
> change? I believe we are still advising explicit http_proxy /
> https_proxy exports prior to running sphinx-build.
And running sphinx-build does not work expecially if there is extensions in the
documentation.
sphinx-build sho
> export PYBUILD_AFTER_BUILD={interpreter} setup.py build_man
Thanks, The only drawback I see with this solution is that I want to run
dh_auto_build 2 times,
- 1 for the arch part (pyhon modules, extensions and manpages)
- 2 for the indep part (doc build)
nevertheless thans a lot it is flexxib
Hello piotr
> if you want to test all requested Python interpreters:
I prefer this solution in order to check that the built extensions are working
for all the python interpreters.
The doc use autodoc so it is nice to have this functionnality
| override_dh_auto_build:
| dh_auto_build -- -
> Simplest I can think of would be to build the extensions inplace
> followed by the call to build_man. Something like:
> override_dh_auto_build:
> dh_auto_build
> python3 setup.py build_ext --inplace
> python3 setup.py build_man
I do not want to build once more the ext (i
11 matches
Mail list logo
