Date: Sun, 06 Aug 2017 14:08:12 +0000 From: bugzilla-noreply@freebsd.org To: python@FreeBSD.org Subject: [Bug 213636] math/py-matplotlib: Fails to build with python3 Message-ID: <bug-213636-21822-auvdhmYhRJ@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-213636-21822@https.bugs.freebsd.org/bugzilla/> References: <bug-213636-21822@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D213636 --- Comment #13 from Kubilay Kocak <koobs@FreeBSD.org> --- (In reply to rsmith from comment #12) It's possible (and I believe there are existing cases in the tree), but that may or may not be the correct, right or best way to address the issue, say versus slave ports (port per backend or similar, or other methods. Other options to consider: - Scope/set USES=3Dpython:<version-spec> per OPTION rather than un-conditio= nally - Scope/set OPTIONS_DEFINE based on python version (only adding them for relevant versions) - Creative use of OPTION_IMPLIES and/or OPTIONS_PREVENTS I haven't researched this to the point where I know the entire matrix of backends and their dependencies, so I can't comment too much on which of the above (or combination of the above) would best suit, but the port (and port= s in general) should be as declarative as possible with regard to options, dependencies and their relationships. On py3-* ports, they are temporary workarounds so they cant be considered a= s an ultimate/final solution to this "backend option mutual exclusion of python support" issue. --=20 You are receiving this mail because: You are on the CC list for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-213636-21822-auvdhmYhRJ>