Hi, I am trying to build cmake with the the build options of just MANPAGES with uses py-sphinx to build the respective manpages. I am hitting a couple of issues. Firstly, in order to build with python36, and having looked at the Makefile, i have to specify PY_FLAVOR=py36 rather than just FLAVOR=py36 which seems to differ to other ports. root@server:/usr/ports/devel/cmake # make FLAVOR=py36 install clean ===> cmake-3.11.0 FLAVOR is defined (to py36) while this port does not have FLAVORS.. *** Error code 1 Specifying PY_FLAVOR=py36 does work and instigates the build/install of the dependant py36 python packages. Secondly, even with PY_FLAVOR=py36 stated and cmake picking up py36-sphinx being installed, cmake fails to install with the error of ------ root@server:/usr/ports/devel/cmake # make PY_FLAVOR=py36 all install clean ===> cmake-3.11.0 depends on executable: sphinx-build - not found ===> cmake-3.11.0 depends on executable: sphinx-build - not found *** Error code 1 Stop. make[1]: stopped in /usr/ports/devel/cmake *** Error code 1 Stop. make: stopped in /usr/ports/devel/cmake ------ root@server:~ # pkg info | grep py36-sphinx py36-sphinx-1.6.5_1,1 Python documentation generator py36-sphinx_rtd_theme-0.2.4 Mobile-friendly py-sphinx theme py36-sphinxcontrib-websupport-1.0.1 Sphinx API for Web Apps root@server:~ #
devel/viewvc is another port with only PY_FLAVORS in use. I'm pretty sure that's because it -- just like cmake -- doesn't actually have a FLAVOR for itself. Or devel/ahven, that's even closer in form because it, too, uses sphinx for documentation building. So the thing is that the Makefile for CMake is incomplete in how it deals with the flavorized-sphinx: - needs ${PYTHON_PKGNAMEPREFIX} - needs to ${REINPLACE_CMD} the flavorized-sphinx into the build
I don't think this is a supported scenario after all. Basically cmake wants "sphinx from the system default Python version", whatever that is. There's no point to building the manpages with a sphinx for a specific Python version. The examples I mentioned previously, explicitly use Python 2.7 and fiddling with PY_FLAVOR doesn't do much except break their build, too.
I think, ports r460715 should be backed out. Depending on unsuffixed binaries requires default flavor, not one the port has requested. To illustrate change USES=python:env to USES=python:3.6,env while PYTHON_DEFAULT remains at 2.7.
(In reply to Jan Beich from comment #3) Or we could just change it to ${PYTHON_PKGNAMEPREFIX}sphinx>0:textproc/py-sphinx@${PY_FLAVOR} which will still depend on the default python flavor, but should not fail, and just bring that in. As this is a build-only dependency, I don't quite see why there is a need to build it with a non-default one. mfg Tobias
A commit references this bug: Author: tcberner Date: Tue May 8 16:36:01 UTC 2018 New revision: 469382 URL: https://svnweb.freebsd.org/changeset/ports/469382 Log: Update devel/cmake to 3.11.1 Exp-run by: antoine PR: 227824 PR: 227573 Changes: head/devel/cmake/Makefile head/devel/cmake/distinfo head/devel/cmake-doc/Makefile head/devel/cmake-gui/Makefile
(In reply to Tobias C. Berner from comment #4) > ${PYTHON_PKGNAMEPREFIX}sphinx>0:textproc/py-sphinx@${PY_FLAVOR} > which will still depend on the default python flavor, but should > not fail, and just bring that in. What if a user requests different python version directly or as a dependency via another port? Obviously, the build would break due to missing sphinx-build (unsuffixed) binary. $ make -V BUILD_DEPENDS:M\*sphinx\* WITH=MANPAGES FLAVOR=py36 -C/usr/ports/devel/cmake py36-sphinx>0:textproc/py-sphinx@py36 > As this is a build-only dependency, I don't quite see > why there is a need to build it with a non-default one. Why pretend to support flavors then i.e., request flavor without BINARY_ALIAS=sphinx-build=sphinx-build-${PYTHON_VER}? Flavors are not a cargo cult, there're times when they shouldn't be used. I still think ports r460715 should be backed out to reduce complexity and fix non-default python version by explicitly not supporting it.
Hello, any progress on this?
I think I agree with Jan -- this added complexity of flavored sphinx, when really what we need is "the default sphinx, whatevs", ought to be backed out. The original commit that introduced flavors is light on justification, and we've been messing around ever since. It'd need someone to actually test it in these configurations, though.
Moin moin r460715 has been backed out again. mfg Tobias
A commit references this bug: Author: tcberner Date: Sat Nov 24 12:08:59 UTC 2018 New revision: 485766 URL: https://svnweb.freebsd.org/changeset/ports/485766 Log: Back out r460715 and only support default python version for sphinx dependency. PR: 227573 Changes: head/devel/cmake/Makefile