Bug 224030 - devel/cmake: fails to build with flavors; py-sphinx missing
Summary: devel/cmake: fails to build with flavors; py-sphinx missing
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: freebsd-kde (group)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-12-02 00:04 UTC by Henrik Hudson
Modified: 2018-04-18 07:54 UTC (History)
6 users (show)

See Also:
tcberner: maintainer-feedback+


Attachments
poudriere build log for cmake (13.02 KB, text/x-log)
2017-12-02 00:05 UTC, Henrik Hudson
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Henrik Hudson 2017-12-02 00:04:13 UTC
Updated to the latest ports with flavors enabled and cmake fails to build with poudriere.

The full error log is attached, but in short:
 cmake-3.9.6 depends on executable: sphinx-build - not found

However, py27-sphinx is installed according to the poudriere log. If I manually install it inside my poudriere build environment it's installing "sphinx-build-2.7"

So, I'm guessing the Makefile for cmake needs to be changed:
MANPAGES_BUILD_DEPENDS= sphinx-build:textproc/py-sphinx

to:

MANPAGES_BUILD_DEPENDS= sphinx-build-2.7:textproc/py-sphinx

or is there some variable we can put there in case it tries to build with a different Python version?
Comment 1 Henrik Hudson 2017-12-02 00:05:09 UTC
Created attachment 188459 [details]
poudriere build log for cmake
Comment 2 Tobias C. Berner freebsd_committer freebsd_triage 2017-12-02 08:07:52 UTC
Hi Henrik

I'm unable to reproduce it here.


mfg Tobias
Comment 3 Peter Wullinger 2017-12-02 08:54:22 UTC
I encountered this yesterday while running up poudriere builds against the "flavored" ports tree.

/usr/local/bin/sphinx-build seems to be not installed in the jail, instead I have /usr/local/bin/sphinx-build-{2.7,3.6}. 

Utilities/Release/create-cmake-release.cmake and Utilities/Sphinx/CMakeLists.txt	have both "sphinx-build" as the name for the executable. I got successful builds by patching both files.

This seems to affect at least one more port (devel/llvm40), but probably all ports that use cmake and look for "sphinx-build".
Comment 4 c.brinkhaus 2017-12-02 16:49:47 UTC
Following Peters suggestion I needed to modify the ports Makefile in the same manner to have a successful build. As a temporary work around I have disabled the man pages. Then py-sphinx is no more pulled in as a dependency.
Comment 5 Adriaan de Groot freebsd_committer freebsd_triage 2017-12-02 17:50:50 UTC
Isn't this py-sphinx changing its contract? It no longer installs bin/sphinx-build, so **anything** that expects that executable is going to fall over. I would expect a (wrapper?) script that is non-suffixed.

Is there a way to state "BUILD_DEPENDS = sphinx-build${INANYFLAVORWHATSOEVERIREALLYDONTCARE}:textproc/py-sphinx" ? Depending on a specific Python version of sphinx-build doesn't seem like a cool thing to do.
Comment 6 Peter Wullinger 2017-12-02 20:26:15 UTC
Side note for anyone trying to track the problem down:

The official packages still have "sphinx-build", but whatever I build locally only have "sphinx-build-?.?", so reproducing the issue requires at least a rebuild of textproc/py-sphinx.
Comment 7 Antoine Brodin freebsd_committer freebsd_triage 2017-12-02 21:58:07 UTC
USE_PYTHON=concurrent installs in bin/ for sphinx

for the default version of python:

sphinx-apidoc@ -> sphinx-apidoc-X.Y
sphinx-apidoc-X.Y
sphinx-autogen@ -> sphinx-autogen-X.Y
sphinx-autogen-X.Y
sphinx-build@ -> sphinx-build-X.Y
sphinx-build-X.Y
sphinx-quickstart@ -> sphinx-quickstart-X.Y
sphinx-quickstart-X.Y

for a non default version of python:

sphinx-apidoc-X.Y
sphinx-autogen-X.Y
sphinx-build-X.Y
sphinx-quickstart-X.Y
Comment 8 Peter Wullinger 2017-12-03 08:03:32 UTC
(In reply to Antoine Brodin from comment #7)
> USE_PYTHON=concurrent installs in bin/ for sphinx
> for the default version of python:
> sphinx-apidoc@ -> sphinx-apidoc-X.Y
I just finished a fresh "DEFAULT_VERSIONS += python=3.6" build and that has

phinx-apidoc@ -> sphinx-apidoc-3.6

so it looks like my python 2.7 build is messed up for ${reason:=me}.
So at least in my case, this is a partial upgrade failure not a ports tree bug.
Comment 9 Peter Wullinger 2017-12-03 14:33:21 UTC
I've been playing with this in my Python 3 default build.

With the current port, cmake build tries to pull in py27-sphinx, which --with Python 3 default-- does not install /usr/local/bin/sphinx-build and configure fails.

I need to do both
MANPAGES_BUILD_DEPENDS= sphinx-build:textproc/py-sphinx@${PY_FLAVOR}
as well as
MANPAGES_USES =         python:build

to get it to pull the native version of py-sphinx. That then results in a successful build.
Comment 10 Sir l33tname 2017-12-03 18:28:11 UTC
I also need to add 

MANPAGES_BUILD_DEPENDS= sphinx-build:textproc/py-sphinx@${PY_FLAVOR}
MANPAGES_USES =         python:build

for it to build here. (I have DEFAULT_VERSIONS += python=3.6)
Comment 11 Tobias C. Berner freebsd_committer freebsd_triage 2017-12-04 05:49:32 UTC
Can you try again after:
https://svnweb.freebsd.org/ports?view=revision&revision=455426
Comment 12 Sir l33tname 2017-12-04 07:55:30 UTC
Just reverted the changes to the make file and rebuilt it. 
Looks fine here.
Comment 13 Henrik Hudson 2017-12-04 15:58:39 UTC
I'm guessing it's due to the python.mk change, but I'm getting a stream of:

make[1]: "/data/poudriere/ports/default/Mk/Uses/python.mk" line 744: if-less endif
make[1]: "/data/poudriere/ports/default/Mk/Uses/python.mk" line 744: if-less endif
make[1]: Fatal errors encountered -- cannot continueeval: make[1]:: not found


when running a portsnap this morning.
Comment 14 Henrik Hudson 2017-12-04 16:05:39 UTC
Egh, looks like this is already fixed. Just need my port mirrors to pickup the change:  https://svnweb.freebsd.org/ports/head/Mk/Uses/python.mk
Comment 15 Henrik Hudson 2017-12-04 19:07:51 UTC
Latest portsnap and build works for me. I'd consider this resolved.
Comment 16 Walter Schwarzenfeld 2018-01-06 23:36:49 UTC
Error still exists (10.4 amd 64)
https://forums.freebsd.org/threads/63518/

please reopen.

MANPAGES_BUILD_DEPENDS= sphinx-build:textproc/py-sphinx@${PY_FLAVOR}
MANPAGES_USES =         python:build

would solve it (like postet above).
Comment 17 Adriaan de Groot freebsd_committer freebsd_triage 2018-04-18 07:54:06 UTC
This was fixed in ports r460715 (amdmi3)