public inbox for gentoo-commits@lists.gentoo.org
 help / color / mirror / Atom feed
From: "Michael Orlitzky" <mjo@gentoo.org>
To: gentoo-commits@lists.gentoo.org
Subject: [gentoo-commits] repo/gentoo:master commit in: dev-python/cvxopt/
Date: Wed, 13 May 2020 20:52:20 +0000 (UTC)	[thread overview]
Message-ID: <1589403079.6fe375dda59821206f8af5da92369908184568b1.mjo@gentoo> (raw)

commit:     6fe375dda59821206f8af5da92369908184568b1
Author:     Michael Orlitzky <mjo <AT> gentoo <DOT> org>
AuthorDate: Wed May 13 20:38:14 2020 +0000
Commit:     Michael Orlitzky <mjo <AT> gentoo <DOT> org>
CommitDate: Wed May 13 20:51:19 2020 +0000
URL:        https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=6fe375dd

dev-python/cvxopt: new revision to cleanup and re-messup some things.

The original purpose of this revision was to refactor the three,
similar, convoluted pipelines that are used to parse the output from
pkg-config and populate cvxopt's FOO_LIB, FOO_LIB_DIR, and FOO_INC_DIR
variables. That was fairly easy: the code to strip out "pthread" and
"m" from `pkg-config --libs-only-l` never worked, so I've dropped
it. After that, the remaining three pipelines all did essentially the
same thing and were combined into a single function that is still
large but now only because it is documented.

Having solved that problem, I made things a bit messy again. I
discovered that most of these variables can be passed an empty string,
resulting in a command line with "empty" arguments like "-L
-L/path/to/wherever" and GCC will accept that. What it won't accept is
the empty "-I" arguments corresponding to the INC_DIR variables. Can
we leave those unset if pkg-config returns the empty string? No!
Because if we do that, then cvxopt will guess the wrong location
(outside of EPREFIX) and attempt to use that. So I added some code to
prepopulate those variables with the right location, and only append
to them when pkg-config gives us something to append.

I think this works better, but I guess we'll see. I've opened an
upstream issue about the empty string problem in these variables. If
they can make the "API" a bit nicer in the future, a lot of the new
ugliness can be reverted.

Package-Manager: Portage-2.3.99, Repoman-2.3.22
Signed-off-by: Michael Orlitzky <mjo <AT> gentoo.org>

 dev-python/cvxopt/cvxopt-1.2.5-r1.ebuild | 174 +++++++++++++++++++++++++++++++
 1 file changed, 174 insertions(+)

diff --git a/dev-python/cvxopt/cvxopt-1.2.5-r1.ebuild b/dev-python/cvxopt/cvxopt-1.2.5-r1.ebuild
new file mode 100644
index 00000000000..c4670120832
--- /dev/null
+++ b/dev-python/cvxopt/cvxopt-1.2.5-r1.ebuild
@@ -0,0 +1,174 @@
+# Copyright 1999-2020 Gentoo Authors
+# Distributed under the terms of the GNU General Public License v2
+
+EAPI=7
+
+PYTHON_COMPAT=( python3_6 python3_7 python3_8 )
+
+inherit distutils-r1 toolchain-funcs
+
+DESCRIPTION="Python package for convex optimization"
+HOMEPAGE="http://cvxopt.org/ https://github.com/cvxopt/cvxopt"
+SRC_URI="https://github.com/${PN}/${PN}/archive/${PV}.tar.gz -> ${P}.tar.gz"
+
+LICENSE="GPL-3"
+SLOT="0"
+KEYWORDS="~amd64 ~x86 ~amd64-linux ~x86-linux"
+IUSE="doc +dsdp examples fftw +glpk gsl test"
+RESTRICT="!test? ( test )"
+
+DEPEND="
+	virtual/blas
+	virtual/lapack
+	sci-libs/amd:0=
+	sci-libs/cholmod:0=
+	sci-libs/colamd:0=
+	sci-libs/suitesparseconfig:0=
+	sci-libs/umfpack:0=
+	dsdp? ( sci-libs/dsdp:0= )
+	fftw? ( sci-libs/fftw:3.0= )
+	glpk? ( >=sci-mathematics/glpk-4.49:0= )
+	gsl? ( sci-libs/gsl:0= )"
+
+RDEPEND="${DEPEND}"
+
+BDEPEND="virtual/pkgconfig
+	doc? ( dev-python/sphinx )
+	test? ( ${RDEPEND} dev-python/nose[${PYTHON_USEDEP}] )"
+
+# The BLAS_LIB and LAPACK_LIB variables (among others) in cvxopt's
+# setup.py are passed in as colon-delimited strings. So, for example,
+# if your blas "l" flags are "-lblas -lcblas", then cvxopt wants
+# "blas;cblas" for BLAS_LIB.
+#
+# The following function takes a flag type ("l", "L", or "I") as its
+# first argument and a list of packages as its remaining arguments. It
+# outputs a list of libraries, library paths, or include paths,
+# respectively, for the given packages, retrieved using pkg-config and
+# deduplicated, in the appropriate format.
+#
+cvxopt_output() {
+	local FLAGNAME="${1}"
+	shift
+	local PACKAGES="${@}"
+
+	local PKGCONFIG_MODE
+	case "${FLAGNAME}" in
+	l) PKGCONFIG_MODE="--libs-only-l";;
+	L) PKGCONFIG_MODE="--libs-only-L";;
+	I) PKGCONFIG_MODE="--cflags-only-I";;
+	*) echo "invalid flag name: ${FLAGNAME}"; exit 1;;
+	esac
+
+	local CVXOPT_OUTPUT=""
+	local PKGCONFIG_ITEM
+	for PKGCONFIG_ITEM in $($(tc-getPKG_CONFIG) ${PKGCONFIG_MODE} ${PACKAGES})
+	do
+	# First strip off the leading "-l", "-L", or "-I", and replace
+	# it with a semicolon...
+	PKGCONFIG_ITEM=";${PKGCONFIG_ITEM#-${FLAGNAME}}"
+
+	# Now check to see if this element is already present in the
+	# list, and skip it if it is. This eliminates multiple entries
+	# from winding up in the list when multiple package arguments are
+	# passed to this function.
+	if [[ "${CVXOPT_OUTPUT}" != "${CVXOPT_OUTPUT%${PKGCONFIG_ITEM}}" ]]
+	then
+		# It was already the last entry in the list, so skip it.
+		continue
+	elif [[ "${CVXOPT_OUTPUT}" != "${CVXOPT_OUTPUT%${PKGCONFIG_ITEM};*}" ]]
+	then
+		# It was an earlier entry in the list. These two cases are
+		# separate to ensure that we can e.g. find ";m" at the end
+		# of the list, but that we don't find ";metis" in the process.
+		continue
+	fi
+
+	# It isn't in the list yet, so append it.
+	CVXOPT_OUTPUT+="${PKGCONFIG_ITEM}"
+	done
+
+	# Strip the leading ";" from ";foo;bar" before output.
+	echo "${CVXOPT_OUTPUT#;}"
+}
+
+python_prepare_all() {
+	# Mandatory dependencies.
+	export CVXOPT_BLAS_LIB="$(cvxopt_output l blas)"
+	export CVXOPT_BLAS_LIB_DIR="${EPREFIX}/usr/$(get_libdir);$(cvxopt_output L blas)"
+	export CVXOPT_LAPACK_LIB="$(cvxopt_output l lapack)"
+	export CVXOPT_SUITESPARSE_LIB_DIR="${EPREFIX}/usr/$(get_libdir);$(cvxopt_output L umfpack cholmod amd colamd suitesparseconfig)"
+
+	# Most of these CVXOPT_* variables can be blank or have "empty"
+	# entries and the resulting command-line with e.g. "-L -L/some/path"
+	# won't hurt anything. The INC_DIR variables, however, cause
+	# problems, because at least gcc doesn't like a bare "-I". We
+	# pre-populate these variable with something safe so that setup.py
+	# doesn't look in the wrong place if pkg-config doesn't return any
+	# extra -I directories. This is
+	#
+	#  https://github.com/cvxopt/cvxopt/issues/167
+	#
+	CVXOPT_SUITESPARSE_INC_DIR="${EPREFIX}/usr/include"
+	local SUITESPARSE_LOCAL_INCS="$(cvxopt_output I umfpack cholmod amd colamd suitesparseconfig)"
+	if [[ -n "${SUITESPARSE_LOCAL_INCS}" ]]; then
+		CVXOPT_SUITESPARSE_INC_DIR+=";${SUITESPARSE_LOCAL_INCS}"
+	fi
+	export CVXOPT_SUITESPARSE_INC_DIR
+
+	# optional dependencies
+	if use dsdp; then
+		# no pkg-config file at the moment
+		export CVXOPT_BUILD_DSDP=1
+		export CVXOPT_DSDP_LIB_DIR="${EPREFIX}/usr/$(get_libdir)"
+		export CVXOPT_DSDP_INC_DIR="${EPREFIX}/usr/include"
+	fi
+
+	if use fftw; then
+		export CVXOPT_BUILD_FFTW=1
+		export CVXOPT_FFTW_LIB_DIR="${EPREFIX}/usr/$(get_libdir);$(cvxopt_output L fftw3)"
+		CVXOPT_FFTW_INC_DIR="${EPREFIX}/usr/include"
+		FFTW_LOCAL_INCS="$(cvxopt_output I fftw3)"
+		if [[ -n "${FFTW_LOCAL_INCS}" ]]; then
+			CVXOPT_FFTW_INC_DIR+=";${FFTW_LOCAL_INCS}"
+		fi
+		export CVXOPT_FFTW_INC_DIR
+	fi
+
+	if use glpk; then
+		# no pkg-config file at the moment
+		export CVXOPT_BUILD_GLPK=1
+		export CVXOPT_GLPK_LIB_DIR="${EPREFIX}/usr/$(get_libdir)"
+		export CVXOPT_GLPK_INC_DIR="${EPREFIX}/usr/include"
+	fi
+
+	if use gsl; then
+		export CVXOPT_BUILD_GSL=1
+		export CVXOPT_GSL_LIB_DIR="${EPREFIX}/usr/$(get_libdir);$(cvxopt_output L gsl)"
+		CVXOPT_GSL_INC_DIR="${EPREFIX}/usr/include"
+		GSL_LOCAL_INCS="$(cvxopt_output I gsl)"
+		if [[ -n "${GSL_LOCAL_INCS}" ]]; then
+			CVXOPT_GSL_INC_DIR+=";${GSL_LOCAL_INCS}"
+		fi
+		export CVXOPT_GSL_INC_DIR
+	fi
+
+	distutils-r1_python_prepare_all
+}
+
+python_compile_all() {
+	use doc && VARTEXFONTS="${T}/fonts" emake -C doc -B html
+}
+
+python_test() {
+	PYTHONPATH="${BUILD_DIR}"/lib nosetests -v || die
+}
+
+python_install_all() {
+	use doc && HTML_DOCS=( doc/build/html/. )
+	distutils-r1_python_install_all
+	if use examples; then
+		dodoc -r examples
+		docompress -x "/usr/share/doc/${PF}/examples"
+	fi
+}


             reply	other threads:[~2020-05-13 20:52 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-13 20:52 Michael Orlitzky [this message]
  -- strict thread matches above, loose matches on Subject: below --
2025-03-30  2:04 [gentoo-commits] repo/gentoo:master commit in: dev-python/cvxopt/ Michael Orlitzky
2024-09-15 18:10 Arthur Zamarin
2024-06-18 17:59 Michał Górny
2023-10-29 19:52 Michał Górny
2023-10-29 19:52 Michał Górny
2023-08-10  2:53 Michał Górny
2023-05-11  8:08 Michał Górny
2023-05-11  6:26 Michał Górny
2023-04-07 13:38 Michał Górny
2022-06-13  7:18 Michał Górny
2022-06-04 17:48 Michał Górny
2022-05-16 13:11 Michał Górny
2022-03-09 18:26 Arthur Zamarin
2021-10-17  7:41 Michał Górny
2021-09-20 21:19 Michał Górny
2021-02-20 10:10 Michał Górny
2021-01-27  4:27 Sam James
2020-07-31 22:33 Aaron Bauman
2020-04-19 23:19 Michael Orlitzky
2020-02-04 19:47 Michał Górny
2018-06-26 20:29 Pacho Ramos
2017-03-04  0:10 Sebastien Fabbro
2017-03-04  0:10 Sebastien Fabbro
2015-12-16  8:49 Justin Lecher

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1589403079.6fe375dda59821206f8af5da92369908184568b1.mjo@gentoo \
    --to=mjo@gentoo.org \
    --cc=gentoo-commits@lists.gentoo.org \
    --cc=gentoo-dev@lists.gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox