Bug 227573 - devel/cmake build issues with py36
Summary: devel/cmake build issues with py36
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: amd64 Any
: --- Affects Many People
Assignee: freebsd-kde (Team)
Depends on:
Reported: 2018-04-17 06:48 UTC by Matthew Leach
Modified: 2018-11-24 12:10 UTC (History)
5 users (show)

See Also:
tcberner: maintainer-feedback+


Note You need to log in before you can comment on or make changes to this bug.
Description Matthew Leach 2018-04-17 06:48:53 UTC

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
*** 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

make[1]: stopped in /usr/ports/devel/cmake
*** Error code 1

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:~ #
Comment 1 Adriaan de Groot freebsd_committer 2018-04-17 14:58:24 UTC
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 to ${REINPLACE_CMD} the flavorized-sphinx into the build
Comment 2 Adriaan de Groot freebsd_committer 2018-04-19 10:48:22 UTC
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.
Comment 3 Jan Beich freebsd_committer 2018-04-24 19:15:44 UTC
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.
Comment 4 Tobias C. Berner freebsd_committer 2018-04-26 04:42:31 UTC
(In reply to Jan Beich from comment #3)

Or we could just change it to 
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
Comment 5 commit-hook freebsd_committer 2018-05-08 16:36:25 UTC
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

  Update devel/cmake to 3.11.1

  Exp-run by:	antoine
  PR:		227824
  PR:		227573

Comment 6 Jan Beich freebsd_committer 2018-05-11 16:19:37 UTC
(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

> 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.
Comment 7 Dries Michiels 2018-08-18 15:33:05 UTC
Hello, any progress on this?
Comment 8 Adriaan de Groot freebsd_committer 2018-08-20 08:09:45 UTC
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.
Comment 9 Tobias C. Berner freebsd_committer 2018-11-24 12:09:22 UTC
Moin moin

r460715 has been backed out again.

mfg Tobias
Comment 10 commit-hook freebsd_committer 2018-11-24 12:10:02 UTC
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

  Back out r460715 and only support default python version for sphinx dependency.

  PR:		227573