Re: [gentoo-dev] RFC: new eclass - pkgconfig.eclass
Le jeudi 29 novembre 2012 à 08:52 +0100, justin a écrit : > Currently we have an eselect module to switch between different > implementations by setting /usr/lib/lib[blas,lapack].so to the selected > implementation. > > This has two drawbacks, which some of you might already of hit: > 1. They seem to be not completely API/ABI compatible (I don't which one > is correct here. And please don't be nitpicking on this point). So > switching would mean recompilation of all packages linked against it > before, otherwise you might get runtime errors. This takes time and > triggers point 2. > > 2. As andy showed we should stick with specific implementations for > specific tasks. The current way flattens this out to be optimal for some > and suboptimal for others. > > Now, there has been a lot of effort around Andy and Sebastien to solve > this problem. The solution is simple: don't install any libblas.so or > liblapack.so in libdir, but instead make the pkg-config module > eselectable and force packages to used pkg-config. Nearly (I think its > 100%) of the packages in the tree already use pkg-config to detect > blas/lapack. I think I understand the problem now. You should not patch/generate .pc files but install them to an implementation specific subdirectory. That way, you just have to append that path to PKGCONFIG_PATH when configuring your package using blas and you should be able to transparently select which implementation to get without further patching of either upstream or downstream packages. -- Gilles Dartiguelongue Gentoo signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] RFC: new eclass - pkgconfig.eclass
On Thu, 29 Nov 2012 08:52:01 +0100 justin wrote: > The only remaining problem is on the implementation side. As you can > imagine, this effort is nothing in which the upstreams are really > interested in. Therefore most of our .pc files are created inside the > ebuild. Eventually they will find their way back upstream, but currently > this is something gentoo specific, it's about choices. > > The eclass should just be a reduction of redundant code. And of course > its not meant to be a replacement to upstream work on packages with sane > buildsystems. Its just a last resort for corner cases like our > lapack/blas stuff, which do not have any reasonable option. > > I hope this clears my intention and makes it reasonable to have this eclass, Nope, it doesn't. If the pkg-config file is created within an ebuild (or eclass), it is *completely unsuitable* to go anywhere. You should write a template, preferably 'mostly' compatible with the build system and put it into FILESDIR. Even if it's going to be redundant. This way, we have a simple, ready, clean, constant file which can be sent upstream or copied by any other distro. It also makes clear that the file is Gentoo-specific. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: new eclass - pkgconfig.eclass
On 29/11/12 09:48, Gilles Dartiguelongue wrote: > Le jeudi 29 novembre 2012 à 08:52 +0100, justin a écrit : >> Currently we have an eselect module to switch between different >> implementations by setting /usr/lib/lib[blas,lapack].so to the selected >> implementation. >> >> This has two drawbacks, which some of you might already of hit: >> 1. They seem to be not completely API/ABI compatible (I don't which one >> is correct here. And please don't be nitpicking on this point). So >> switching would mean recompilation of all packages linked against it >> before, otherwise you might get runtime errors. This takes time and >> triggers point 2. >> >> 2. As andy showed we should stick with specific implementations for >> specific tasks. The current way flattens this out to be optimal for some >> and suboptimal for others. >> >> Now, there has been a lot of effort around Andy and Sebastien to solve >> this problem. The solution is simple: don't install any libblas.so or >> liblapack.so in libdir, but instead make the pkg-config module >> eselectable and force packages to used pkg-config. Nearly (I think its >> 100%) of the packages in the tree already use pkg-config to detect >> blas/lapack. > > I think I understand the problem now. You should not patch/generate .pc > files but install them to an implementation specific subdirectory. > If I get you correctly you are assuming that we have pkgconfig files for all implementations coming from upstreams. That's not correct, we have nearly none. So we need to generate them our own. And yes this need to be sent upstream. That's the reason for the eclass. > That way, you just have to append that path to PKGCONFIG_PATH when > configuring your package using blas and you should be able to > transparently select which implementation to get without further > patching of either upstream or downstream packages. > This would mean that the pkg maintainer decides the implementation. But we leave this choice to the user which works fine. And we have a working eselect based solution. justin signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Using emerge-webrsync to simplify the handbook
On 28 November 2012 13:54, Richard Yao wrote: > We could slightly simplify the handbook installation procedure if we > told people to use emerge-webrsync to fetch the initial snapshot. What > do people think? > Seems a good improvement to me. -- Regards, Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2
Re: [gentoo-dev] RFC: new eclass - pkgconfig.eclass
On 29/11/12 09:52, Michał Górny wrote: > On Thu, 29 Nov 2012 08:52:01 +0100 > justin wrote: > >> The only remaining problem is on the implementation side. As you can >> imagine, this effort is nothing in which the upstreams are really >> interested in. Therefore most of our .pc files are created inside the >> ebuild. Eventually they will find their way back upstream, but currently >> this is something gentoo specific, it's about choices. >> >> The eclass should just be a reduction of redundant code. And of course >> its not meant to be a replacement to upstream work on packages with sane >> buildsystems. Its just a last resort for corner cases like our >> lapack/blas stuff, which do not have any reasonable option. >> >> I hope this clears my intention and makes it reasonable to have this eclass, > > Nope, it doesn't. If the pkg-config file is created within an ebuild > (or eclass), it is *completely unsuitable* to go anywhere. > > You should write a template, preferably 'mostly' compatible with > the build system and put it into FILESDIR. Even if it's going to be > redundant. This way, we have a simple, ready, clean, constant file > which can be sent upstream or copied by any other distro. It also makes > clear that the file is Gentoo-specific. > > Just to be clear on some points. 1. We are _not_ talking about packages like e.g. gnome libs which have upstreams who know how to work with buildsystem and use sane standard ones. Those love to accept patches making things smoother. Most of the sci upstreams are using custom shell scripts or badly written makefiles. They normal don't get the point in accepting things from us. 2. Even if we would directly start working with upstream on a solution, we would not have something in broad distribution downstream before we all will retire from gentoo. (If you like, you can go to intel and tell them to have a buildsystem which creates the necessary files. This will not happen in near future.) 3. Most distribution, as they happen to be binary, only build against one implementation usually the reference. And a significantly large number even rename their libraries. So no sense to convince them to use standard pc files. So no need for us to force a solution with upstream now, before proceeding with gentoo. We need to think about gentoo now. Therefore a manual creation of those files is what we are doing now. With or without an eclass. Now back to your good argument. You are right, we should work with some sort of template. I think for the reference implementations this can be realized quite easily, as they moved to cmake quite recently. For most of the others it will be quite some work. We will take a look into their buildsystem and see what we can achieve. Thanks, Justin signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: new eclass - pkgconfig.eclass
again, even if there are corner cases which cannot be dealt with in a different way... having an eclass function like the mentioned one is bad, cause it suggests that this is a way to fix things. It's not. Application developers running gentoo might think "oh great, there is a pkgconfig file for this, so I can use it in my Makefile". Then a Fedora packager comes across this package and realizes a compile failure until he notices the build system is calling for a pkgconfig file that cannot be found anywhere. So he contacts this developer and asks which distro he is using. This already happened for me multiple times and the answers was "debian". All this sounds like a very dirty workaround and if you need it, then do it, but _don't_ create an eclass, cause it's not a good thing to standardize. These files should _not_ be distro-dependant. Try to find other solutions. -1 for this eclass
Re: [gentoo-dev] RFC: new eclass - pkgconfig.eclass
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 28/11/12 08:26 PM, Richard Yao wrote: > On 11/28/2012 05:21 PM, Michał Górny wrote: >> On Wed, 28 Nov 2012 22:49:14 +0100 Justin >> wrote: >> >>> Hi, >>> >>> and another one. >>> >>> Problem: Some packages aren't lucky and their buildsystem >>> doesn't create pkg-config files out of the box. >>> >>> Solution: Create them by hand. >> >> Result: packages which fail to build on distributions other than >> Gentoo because their authors were using Gentoo and didn't knew >> that the pkg-config aren't anywhere else. >> > > I suspect that the .pc files would probably be available if people > installed -dev packages. If not, people can blame the distribution > developers for breaking things. > They wouldn't be if upstream doesn't provide them and only Gentoo did, which is what this eclass would be for.. Standard rules of development, if the lib doesn't provide a .pc file then you can't use pkg-config to configure your software for it. There's no point in providing a .pc file if nothing is going to use it, and we (gentoo developers) definitely do not want to end up patching and maintaining patches on both a lib and all its rdeps just so that it support pkgconfig. (i came across this situation already and learned a bit the hard way with spidermonkey. It sucked to have to use checks for filenames and special defines in header files to find the right libs, but that was still the only "right" way to do it until spidermonkey upstream finally started bundling a .pc) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iF4EAREIAAYFAlC3ZLkACgkQ2ugaI38ACPANHAD/RtWy8/K6U58PQWvk7CyfRSth 1WrlSwbjJslioWfaRvYA/RMnJX9/Js1YkYHZBGHk28dK2GzwrxJh872MqsCqWEVR =4EwJ -END PGP SIGNATURE-
[gentoo-dev] [PATCH 2/4] autotools-multilib: use and support BUILD_DIR.
---
gx86/eclass/autotools-multilib.eclass | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/gx86/eclass/autotools-multilib.eclass
b/gx86/eclass/autotools-multilib.eclass
index f6d1feb..541e934 100644
--- a/gx86/eclass/autotools-multilib.eclass
+++ b/gx86/eclass/autotools-multilib.eclass
@@ -38,17 +38,19 @@ IUSE=multilib
# @USAGE: argv...
# @DESCRIPTION:
# If multilib support is enabled, sets the toolchain up for each
-# supported ABI along with the ABI variable and correct
-# AUTOTOOLS_BUILD_DIR, and runs the given commands with them.
+# supported ABI along with the ABI variable and correct BUILD_DIR,
+# and runs the given commands with them.
#
# If multilib support is disabled, it just runs the commands. No setup
# is done.
autotools-multilib_foreach_abi() {
+ local initial_dir=${BUILD_DIR:-${S}}
+
if use multilib; then
local ABI
for ABI in $(get_all_abis); do
multilib_toolchain_setup "${ABI}"
- AUTOTOOLS_BUILD_DIR=${S%%/}-${ABI} "${@}"
+ BUILD_DIR=${initial_dir%%/}-${ABI} "${@}"
done
else
"${@}"
--
1.8.0
[gentoo-dev] autotools-utils & cmake-utils: use common BUILD_DIR var
Currently, each of the mentioned eclasses has its own *_BUILD_DIR. Therefore, if someone needs to provide a custom BUILD_DIR, he needs to set it explicitly for the eclass. This is fine for ebuilds but not really neat for eclasses. The idea is simple: use a common BUILD_DIR instead. For compatibility, export AUTOTOOLS_ & CMAKE_BUILD_DIR as well but prefer the former one. For most of the ebuilds this won't make a difference. I'm attaching an example conversion of pygobject where this would benefit. The idea is quite simple; ebuild calls python_foreach_impl autotools-utils_src_... python_foreach_impl() sets BUILD_DIR for each implementation, autotools-utils phases use that and everything simply works!
[gentoo-dev] [PATCH 1/4] autotools-utils: use common BUILD_DIR variable.
For interoperability with python-r1.
---
gx86/eclass/autotools-utils.eclass | 30 ++
1 file changed, 18 insertions(+), 12 deletions(-)
diff --git a/gx86/eclass/autotools-utils.eclass
b/gx86/eclass/autotools-utils.eclass
index b035dc5..b6bfc96 100644
--- a/gx86/eclass/autotools-utils.eclass
+++ b/gx86/eclass/autotools-utils.eclass
@@ -76,10 +76,10 @@
# }
#
# src_install() {
-# use doc && HTML_DOCS=("${AUTOTOOLS_BUILD_DIR}/apidocs/html/")
+# use doc && HTML_DOCS=("${BUILD_DIR}/apidocs/html/")
# autotools-utils_src_install
# if use examples; then
-# dobin "${AUTOTOOLS_BUILD_DIR}"/foo_example{1,2,3} \\
+# dobin "${BUILD_DIR}"/foo_example{1,2,3} \\
# || die 'dobin examples failed'
# fi
# }
@@ -117,11 +117,14 @@ inherit autotools eutils libtool
EXPORT_FUNCTIONS src_prepare src_configure src_compile src_install src_test
-# @ECLASS-VARIABLE: AUTOTOOLS_BUILD_DIR
+# @ECLASS-VARIABLE: BUILD_DIR
# @DEFAULT_UNSET
# @DESCRIPTION:
# Build directory, location where all autotools generated files should be
# placed. For out of source builds it defaults to ${WORKDIR}/${P}_build.
+#
+# This variable has been called AUTOTOOLS_BUILD_DIR formerly.
+# It is set under that name for compatibility.
# @ECLASS-VARIABLE: AUTOTOOLS_IN_SOURCE_BUILD
# @DEFAULT_UNSET
@@ -183,11 +186,14 @@ EXPORT_FUNCTIONS src_prepare src_configure src_compile
src_install src_test
_check_build_dir() {
: ${ECONF_SOURCE:=${S}}
if [[ -n ${AUTOTOOLS_IN_SOURCE_BUILD} ]]; then
- AUTOTOOLS_BUILD_DIR="${ECONF_SOURCE}"
+ BUILD_DIR="${ECONF_SOURCE}"
else
- : ${AUTOTOOLS_BUILD_DIR:=${WORKDIR}/${P}_build}
+ : ${BUILD_DIR:=${AUTOTOOLS_BUILD_DIR:-${WORKDIR}/${P}_build}}
fi
- echo ">>> Working in BUILD_DIR: \"$AUTOTOOLS_BUILD_DIR\""
+
+ # Backwards compatibility.
+ AUTOTOOLS_BUILD_DIR=${BUILD_DIR}
+ echo ">>> Working in BUILD_DIR: \"${BUILD_DIR}\""
}
# @FUNCTION: remove_libtool_files
@@ -413,20 +419,20 @@ autotools-utils_src_configure() {
# Append user args
econfargs+=("${myeconfargs[@]}")
- mkdir -p "${AUTOTOOLS_BUILD_DIR}" || die "mkdir
'${AUTOTOOLS_BUILD_DIR}' failed"
- pushd "${AUTOTOOLS_BUILD_DIR}" > /dev/null || die
+ mkdir -p "${BUILD_DIR}" || die
+ pushd "${BUILD_DIR}" > /dev/null || die
econf "${econfargs[@]}" "$@"
popd > /dev/null || die
}
# @FUNCTION: autotools-utils_src_compile
# @DESCRIPTION:
-# The autotools src_compile function, invokes emake in specified
AUTOTOOLS_BUILD_DIR.
+# The autotools src_compile function, invokes emake in specified BUILD_DIR.
autotools-utils_src_compile() {
debug-print-function ${FUNCNAME} "$@"
_check_build_dir
- pushd "${AUTOTOOLS_BUILD_DIR}" > /dev/null || die
+ pushd "${BUILD_DIR}" > /dev/null || die
emake "$@" || die 'emake failed'
popd > /dev/null || die
}
@@ -443,7 +449,7 @@ autotools-utils_src_install() {
debug-print-function ${FUNCNAME} "$@"
_check_build_dir
- pushd "${AUTOTOOLS_BUILD_DIR}" > /dev/null || die
+ pushd "${BUILD_DIR}" > /dev/null || die
emake DESTDIR="${D}" "$@" install || die "emake install failed"
popd > /dev/null || die
@@ -490,7 +496,7 @@ autotools-utils_src_test() {
debug-print-function ${FUNCNAME} "$@"
_check_build_dir
- pushd "${AUTOTOOLS_BUILD_DIR}" > /dev/null || die
+ pushd "${BUILD_DIR}" > /dev/null || die
# Run default src_test as defined in ebuild.sh
default_src_test
popd > /dev/null || die
--
1.8.0
[gentoo-dev] [PATCH 3/4] cmake-utils: support common BUILD_DIR variable.
---
gx86/eclass/cmake-utils.eclass | 33 +++--
1 file changed, 19 insertions(+), 14 deletions(-)
diff --git a/gx86/eclass/cmake-utils.eclass b/gx86/eclass/cmake-utils.eclass
index 2129ebf..26fc1c1 100644
--- a/gx86/eclass/cmake-utils.eclass
+++ b/gx86/eclass/cmake-utils.eclass
@@ -114,12 +114,15 @@ _use_me_now_inverted() {
fi
}
-# @ECLASS-VARIABLE: CMAKE_BUILD_DIR
+# @ECLASS-VARIABLE: BUILD_DIR
# @DESCRIPTION:
# Build directory where all cmake processed files should be generated.
# For in-source build it's fixed to ${CMAKE_USE_DIR}.
# For out-of-source build it can be overriden, by default it uses
# ${WORKDIR}/${P}_build.
+#
+# This variable has been called CMAKE_BUILD_DIR formerly.
+# It is set under that name for compatibility.
# @ECLASS-VARIABLE: CMAKE_BUILD_TYPE
# @DESCRIPTION:
@@ -163,12 +166,14 @@ _check_build_dir() {
: ${CMAKE_USE_DIR:=${S}}
if [[ -n ${CMAKE_IN_SOURCE_BUILD} ]]; then
# we build in source dir
- CMAKE_BUILD_DIR="${CMAKE_USE_DIR}"
+ BUILD_DIR="${CMAKE_USE_DIR}"
else
- : ${CMAKE_BUILD_DIR:=${WORKDIR}/${P}_build}
+ : ${BUILD_DIR:=${CMAKE_BUILD_DIR:-${WORKDIR}/${P}_build}}
fi
- mkdir -p "${CMAKE_BUILD_DIR}"
- echo ">>> Working in BUILD_DIR: \"$CMAKE_BUILD_DIR\""
+ CMAKE_BUILD_DIR=${BUILD_DIR}
+
+ mkdir -p "${BUILD_DIR}"
+ echo ">>> Working in BUILD_DIR: \"$BUILD_DIR\""
}
# Determine which generator to use
@@ -328,7 +333,7 @@ enable_cmake-utils_src_configure() {
fi
# Prepare Gentoo override rules (set valid compiler, append CPPFLAGS
etc.)
- local build_rules=${CMAKE_BUILD_DIR}/gentoo_rules.cmake
+ local build_rules=${BUILD_DIR}/gentoo_rules.cmake
cat > "${build_rules}" <<- _EOF_
SET (CMAKE_AR $(type -P $(tc-getAR)) CACHE FILEPATH "Archive
manager" FORCE)
SET (CMAKE_C_COMPILER $(type -P $(tc-getCC)) CACHE FILEPATH "C
compiler" FORCE)
@@ -364,7 +369,7 @@ enable_cmake-utils_src_configure() {
fi
# Common configure parameters (invariants)
- local common_config=${CMAKE_BUILD_DIR}/gentoo_common_config.cmake
+ local common_config=${BUILD_DIR}/gentoo_common_config.cmake
local libdir=$(get_libdir)
cat > "${common_config}" <<- _EOF_
SET (LIB_SUFFIX ${libdir/lib} CACHE STRING "library path
suffix" FORCE)
@@ -396,7 +401,7 @@ enable_cmake-utils_src_configure() {
"${MYCMAKEARGS}"
)
- pushd "${CMAKE_BUILD_DIR}" > /dev/null
+ pushd "${BUILD_DIR}" > /dev/null
debug-print "${LINENO} ${ECLASS} ${FUNCNAME}: mycmakeargs is
${mycmakeargs_local[*]}"
echo "${CMAKE_BINARY}" "${cmakeargs[@]}" "${CMAKE_USE_DIR}"
"${CMAKE_BINARY}" "${cmakeargs[@]}" "${CMAKE_USE_DIR}" || die "cmake
failed"
@@ -418,7 +423,7 @@ cmake-utils_src_make() {
debug-print-function ${FUNCNAME} "$@"
_check_build_dir
- pushd "${CMAKE_BUILD_DIR}" > /dev/null
+ pushd "${BUILD_DIR}" > /dev/null
if [[ $(_generator_to_use) = Ninja ]]; then
# first check if Makefile exist otherwise die
[[ -e build.ninja ]] || die "Makefile not found. Error during
configure stage."
@@ -444,7 +449,7 @@ enable_cmake-utils_src_install() {
debug-print-function ${FUNCNAME} "$@"
_check_build_dir
- pushd "${CMAKE_BUILD_DIR}" > /dev/null
+ pushd "${BUILD_DIR}" > /dev/null
if [[ $(_generator_to_use) = Ninja ]]; then
DESTDIR=${D} ninja install "$@" || die "died running ninja
install"
base_src_install_docs
@@ -467,7 +472,7 @@ enable_cmake-utils_src_test() {
local ctestargs
_check_build_dir
- pushd "${CMAKE_BUILD_DIR}" > /dev/null
+ pushd "${BUILD_DIR}" > /dev/null
[[ -e CTestTestfile.cmake ]] || { echo "No tests found. Skipping.";
return 0 ; }
[[ -n ${TEST_VERBOSE} ]] && ctestargs="--extra-verbose
--output-on-failure"
@@ -479,13 +484,13 @@ enable_cmake-utils_src_test() {
else
if [[ -n "${CMAKE_YES_I_WANT_TO_SEE_THE_TEST_LOG}" ]] ; then
# on request from Diego
- eerror "Tests failed. Test log
${CMAKE_BUILD_DIR}/Testing/Temporary/LastTest.log follows:"
+ eerror "Tests failed. Test log
${BUILD_DIR}/Testing/Temporary/LastTest.log follows:"
eerror "--START TEST
LOG--"
- cat "${CMAKE_BUILD_DIR}/Testing/Temporary/LastTest.log"
+ cat "${BUILD_DIR}/Testing/Temporary/LastTest.log"
eerror "--END TEST
LOG"
die "Tests failed."
else
- die "Tests failed. When yo
[gentoo-dev] [PATCH 4/4] Example conversion of pygobject to python-r1 + autotools-utils.
---
.../dev-python/pygobject/pygobject-3.2.2-r1.ebuild | 106 +
1 file changed, 106 insertions(+)
create mode 100644 gx86/dev-python/pygobject/pygobject-3.2.2-r1.ebuild
diff --git a/gx86/dev-python/pygobject/pygobject-3.2.2-r1.ebuild
b/gx86/dev-python/pygobject/pygobject-3.2.2-r1.ebuild
new file mode 100644
index 000..289eace
--- /dev/null
+++ b/gx86/dev-python/pygobject/pygobject-3.2.2-r1.ebuild
@@ -0,0 +1,106 @@
+# Copyright 1999-2012 Gentoo Foundation
+# Distributed under the terms of the GNU General Public License v2
+# $Header:
/var/cvsroot/gentoo-x86/dev-python/pygobject/pygobject-3.2.2.ebuild,v 1.5
2012/09/28 05:45:45 mattst88 Exp $
+
+EAPI="4"
+GCONF_DEBUG="no"
+PYTHON_COMPAT=( python2_6 python2_7 python3_1 python3_2 )
+AUTOTOOLS_AUTORECONF=1
+
+inherit autotools-utils eutils gnome2 python-r1 virtualx
+
+DESCRIPTION="GLib's GObject library bindings for Python"
+HOMEPAGE="http://www.pygtk.org/";
+
+LICENSE="LGPL-2.1+"
+SLOT="3"
+KEYWORDS="alpha ~amd64 ~arm ~hppa ~ia64 ~mips ~ppc ~ppc64 ~sh ~sparc ~x86
~amd64-fbsd ~x86-fbsd ~x86-interix ~amd64-linux ~x86-linux ~ppc-macos
~x64-macos ~x86-macos ~sparc-solaris ~x64-solaris ~x86-solaris"
+IUSE="+cairo examples test +threads" # doc
+REQUIRED_USE="test? ( cairo )"
+
+COMMON_DEPEND=">=dev-libs/glib-2.31.0:2
+ >=dev-libs/gobject-introspection-1.31.20
+ virtual/libffi
+ ${PYTHON_DEPS}
+ cairo? ( >=dev-python/pycairo-1.10.0 )"
+DEPEND="${COMMON_DEPEND}
+ test? (
+ dev-libs/atk[introspection]
+ media-fonts/font-cursor-misc
+ media-fonts/font-misc-misc
+ x11-libs/gdk-pixbuf:2[introspection]
+ x11-libs/gtk+:3[introspection]
+ x11-libs/pango[introspection] )
+ virtual/pkgconfig"
+# docs disabled for now per upstream default since they are very out of date
+# doc? (
+# app-text/docbook-xml-dtd:4.1.2
+# dev-libs/libxslt
+# >=app-text/docbook-xsl-stylesheets-1.70.1 )
+
+#RESTRICT=test
+
+# We now disable introspection support in slot 2 per upstream recommendation
+# (see https://bugzilla.gnome.org/show_bug.cgi?id=642048#c9); however,
+# older versions of slot 2 installed their own site-packages/gi, and
+# slot 3 will collide with them.
+RDEPEND="${COMMON_DEPEND}
+ !
Re: [gentoo-dev] RFC: new eclass - pkgconfig.eclass
On 29/11/12 14:16, hasufell wrote: > > again, even if there are corner cases which cannot be dealt with in a > different way... > > having an eclass function like the mentioned one is bad, cause it > suggests that this is a way to fix things. It's not. Application > developers running gentoo might think "oh great, there is a pkgconfig > file for this, so I can use it in my Makefile". Then a Fedora packager > comes across this package and realizes a compile failure until he > notices the build system is calling for a pkgconfig file that cannot be > found anywhere. So he contacts this developer and asks which distro he > is using. Standard autotools based packages always use --with-blas= so it is pretty simple for us to make it to --with-blas="$(pkg-config --libs blas)" same thing goes for cmake and -DBLAS_LIBRARIES="$(pkg-config --libs blas)" This game has been played since ever, because blas/lapack are bundled in more then 80% of the packages using it. So we are used to patch them to use system libs. So why not making our lives easier by having a pkg-config option? justin signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] blas .pc files (was RFC: new eclass - pkgconfig.eclass)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 29/11/12 09:56 AM, justin wrote: > > Standard autotools based packages always use > > --with-blas= > > so it is pretty simple for us to make it to > > --with-blas="$(pkg-config --libs blas)" > > same thing goes for cmake and > > -DBLAS_LIBRARIES="$(pkg-config --libs blas)" > > This game has been played since ever, because blas/lapack are > bundled in more then 80% of the packages using it. So we are used > to patch them to use system libs. So why not making our lives > easier by having a pkg-config option? > > justin > ..ok remind me again what the .pc files provide you? this is so that you can have slotted blas providers and various packages can choose their preferred one instead of having to use the eselected one? or... -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iF4EAREIAAYFAlC3hIEACgkQ2ugaI38ACPCXRAEAs1mM8q5Ue+eRddq1gdcMM8Zq uvMM0qZmGcVQ/QAt/sEA/1NIn/SDAycCq70U4ZlAlIJ/YKL2jLT04Q1YCLQwyZKx =GseU -END PGP SIGNATURE-
Re: [gentoo-dev] blas .pc files (was RFC: new eclass - pkgconfig.eclass)
On 29/11/12 16:51, Ian Stakenvicius wrote: > On 29/11/12 09:56 AM, justin wrote: > >> Standard autotools based packages always use > >> --with-blas= > >> so it is pretty simple for us to make it to > >> --with-blas="$(pkg-config --libs blas)" > >> same thing goes for cmake and > >> -DBLAS_LIBRARIES="$(pkg-config --libs blas)" > >> This game has been played since ever, because blas/lapack are >> bundled in more then 80% of the packages using it. So we are used >> to patch them to use system libs. So why not making our lives >> easier by having a pkg-config option? > >> justin > > > ..ok remind me again what the .pc files provide you? this is so that > you can have slotted blas providers and various packages can choose > their preferred one instead of having to use the eselected one? or... > > > > > Not exactly. The user can choose for each package newly by eselecting the wanted implementation. This is the user side. From the pm side we ensure that the choice is really respected by linking against package specific names [1] instead of the generic ones e.g. libblas.so. And this can be achieved in an easy way by using pkg-config. justin 1) # eselect blas set atlas-threads # pkg-config --libs blas -lptf77blas -lm -latlas -lpthread # eselect blas set reference # pkg-config --libs blas -lrefblas signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: new eclass - pkgconfig.eclass
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/29/2012 03:56 PM, justin wrote: > On 29/11/12 14:16, hasufell wrote: >> >> again, even if there are corner cases which cannot be dealt with >> in a different way... >> >> having an eclass function like the mentioned one is bad, cause >> it suggests that this is a way to fix things. It's not. >> Application developers running gentoo might think "oh great, >> there is a pkgconfig file for this, so I can use it in my >> Makefile". Then a Fedora packager comes across this package and >> realizes a compile failure until he notices the build system is >> calling for a pkgconfig file that cannot be found anywhere. So he >> contacts this developer and asks which distro he is using. > > So why not making our lives easier by having a pkg-config option? Did you read what you quoted? Are you saying cross distro interfaces for accessing libraries in build systems are ok to break? Not only are people using foo.pc to compile a package on gentoo, but also when writing a build system for "bar" which might link against "foo". So having largely unused .pc files is the best case, the worst is causing random breakage/annoyance for other distros without even knowing, cause yeah... for us it works. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJQt4wFAAoJEFpvPKfnPDWzVRYH/1GEU5z5wPiNbruYJYrRDFD5 ttjclvPYDsx+4XOjl7ppFS8LsnYr6GQu6qMFC33G6jQyj+lFR/OAzW35aAoa4PDc IzduHa5auP853Kscj+Qx/HHTakm1CCLq8tTjFdiHjlh0khHrTqdH/EdLMqxL9fYq l64wTmXMpwvg11jAd6mEV1kX8+LR1gV6ksE3FPNIuBiiVzYfiqYzsSJa5OuGSQ7X US+krpAXpFb4bvaGRKuhBHa1SOWinUSIPmk6C01faLEbhI4g/DQp6G0NBQPpN4Nh ivMQGo1qWJjUQvcS2BDApeA3R6LLyCczxsYkkXK3czneAMwbaUUoBZwczrRPcQQ= =qZ9+ -END PGP SIGNATURE-
Re: [gentoo-dev] blas .pc files (was RFC: new eclass - pkgconfig.eclass)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/29/2012 05:09 PM, justin wrote: > > Not exactly. The user can choose for each package newly by > eselecting the wanted implementation. This is the user side. From > the pm side we ensure that the choice is really respected by > linking against package specific names [1] instead of the generic > ones e.g. libblas.so. And this can be achieved in an easy way by > using pkg-config. > > justin > > 1) # eselect blas set atlas-threads # pkg-config --libs blas > -lptf77blas -lm -latlas -lpthread > > # eselect blas set reference # pkg-config --libs blas -lrefblas > > My opinion is less strong if you do this only on package level without creating such an eclass and in the way mgorny pointed out with a comment that this is gentoo-specific. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJQt40EAAoJEFpvPKfnPDWzZgoH/2Mes+9TPYRCaCm65z+bLUep l0K4DspA8J71ixRxWwkZmwkpasezd7nB0jLiiOSMsy6MOzot5QXr7MyEHtjW/b9G /1Yk880T8bIDq4ryb19PWhiW90pOYGmdvaEbp5mgvmUSoPAiX24tqNmF/gdhuPaZ DfHVRub+0Mp5LvCHj2xNku5AZOZ5MqkJh2kLmMR0plWF1Z2FW0jtqS1ak3pY6hI8 O8bY1J9Gaym1TF7tcTnsoRz3qb3lRXfZMSPEAaQOpzIa1FhurroVZFNyD8afZlsH S6xRkIn413v969+SAZ9waVoomTnzKgajWvqessddROb6GVD7mBk/Y+EOD9qxlhA= =Sfio -END PGP SIGNATURE-
Re: [gentoo-dev] blas .pc files (was RFC: new eclass - pkgconfig.eclass)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 29/11/12 11:09 AM, justin wrote: > On 29/11/12 16:51, Ian Stakenvicius wrote: >> On 29/11/12 09:56 AM, justin wrote: >> >>> Standard autotools based packages always use >> >>> --with-blas= >> >>> so it is pretty simple for us to make it to >> >>> --with-blas="$(pkg-config --libs blas)" >> >>> same thing goes for cmake and >> >>> -DBLAS_LIBRARIES="$(pkg-config --libs blas)" >> >>> This game has been played since ever, because blas/lapack are >>> bundled in more then 80% of the packages using it. So we are >>> used to patch them to use system libs. So why not making our >>> lives easier by having a pkg-config option? >> >>> justin >> >> >> ..ok remind me again what the .pc files provide you? this is so >> that you can have slotted blas providers and various packages can >> choose their preferred one instead of having to use the eselected >> one? or... >> >> >> >> >> > > Not exactly. The user can choose for each package newly by > eselecting the wanted implementation. This is the user side. From > the pm side we ensure that the choice is really respected by > linking against package specific names [1] instead of the generic > ones e.g. libblas.so. And this can be achieved in an easy way by > using pkg-config. > > justin > > 1) # eselect blas set atlas-threads # pkg-config --libs blas > -lptf77blas -lm -latlas -lpthread > > # eselect blas set reference # pkg-config --libs blas -lrefblas > > Doing this via an eclass that would export BLAS_LIBS and BLAS_CFLAGS (and appending necessary equivalents to mycmakeargs) for src_configure based on what is eselected wouldn't be as easy or easier to do? -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iF4EAREIAAYFAlC3kPMACgkQ2ugaI38ACPCa7gD+M7knL7yghfUe6oejohgV/upw iDJmpCkt5WDZVoqu76EBAJGvMG1TgebSWreHx9RPdXc2RErstr7Cfg0ulfCy/WJ8 =uuBE -END PGP SIGNATURE-
Re: [gentoo-dev] [PATCH 4/4] Example conversion of pygobject to python-r1 + autotools-utils.
First, thanks for this patch, I was planning on converting it but did
not have to do it.
Le jeudi 29 novembre 2012 à 14:40 +0100, Michał Górny a écrit :
> ---
> .../dev-python/pygobject/pygobject-3.2.2-r1.ebuild | 106
> +
> 1 file changed, 106 insertions(+)
> create mode 100644 gx86/dev-python/pygobject/pygobject-3.2.2-r1.ebuild
>
> diff --git a/gx86/dev-python/pygobject/pygobject-3.2.2-r1.ebuild
> b/gx86/dev-python/pygobject/pygobject-3.2.2-r1.ebuild
> new file mode 100644
> index 000..289eace
> --- /dev/null
> +++ b/gx86/dev-python/pygobject/pygobject-3.2.2-r1.ebuild
> @@ -0,0 +1,106 @@
> +# Copyright 1999-2012 Gentoo Foundation
> +# Distributed under the terms of the GNU General Public License v2
> +# $Header:
> /var/cvsroot/gentoo-x86/dev-python/pygobject/pygobject-3.2.2.ebuild,v 1.5
> 2012/09/28 05:45:45 mattst88 Exp $
> +
> +EAPI="4"
> +GCONF_DEBUG="no"
> +PYTHON_COMPAT=( python2_6 python2_7 python3_1 python3_2 )
> +AUTOTOOLS_AUTORECONF=1
> +
> +inherit autotools-utils eutils gnome2 python-r1 virtualx
Please do not mix autotools utils with gnome2 eclass. gnome team does
not support out of tree builds for now. I have plans to integrate this
in the eclass but we found that upstream generally does not test this so
we want to test it more extensively before making this available.
> +# FIXME: With python multiple ABI support, tests return 1 even when they pass
> +src_test() {
> + local DBUS_SESSION_BUS_ADDRESS
> + local GIO_USE_VFS='local' # prevents odd issues with deleting ${T}/.gvfs
> + local VIRTUALX_COMMAND=python_test
> +
> + export GIO_USE_VFS
> +
> + python_foreach_impl virtualmake
> +
> + python_execute_function -s testing
> +}
> +
dbus variables needs to be unset for tests to work when you do your
builds from a terminal started from your desktop, is that really
equivalent ?
--
Gilles Dartiguelongue
Gentoo
Re: [gentoo-dev] RFC: new eclass - pkgconfig.eclass
Le jeudi 29 novembre 2012 à 10:07 +0100, justin a écrit : > On 29/11/12 09:48, Gilles Dartiguelongue wrote: > > Le jeudi 29 novembre 2012 à 08:52 +0100, justin a écrit : > >> Currently we have an eselect module to switch between different > >> implementations by setting /usr/lib/lib[blas,lapack].so to the selected > >> implementation. > >> > >> This has two drawbacks, which some of you might already of hit: > >> 1. They seem to be not completely API/ABI compatible (I don't which one > >> is correct here. And please don't be nitpicking on this point). So > >> switching would mean recompilation of all packages linked against it > >> before, otherwise you might get runtime errors. This takes time and > >> triggers point 2. > >> > >> 2. As andy showed we should stick with specific implementations for > >> specific tasks. The current way flattens this out to be optimal for some > >> and suboptimal for others. > >> > >> Now, there has been a lot of effort around Andy and Sebastien to solve > >> this problem. The solution is simple: don't install any libblas.so or > >> liblapack.so in libdir, but instead make the pkg-config module > >> eselectable and force packages to used pkg-config. Nearly (I think its > >> 100%) of the packages in the tree already use pkg-config to detect > >> blas/lapack. > > > > I think I understand the problem now. You should not patch/generate .pc > > files but install them to an implementation specific subdirectory. > > > > If I get you correctly you are assuming that we have pkgconfig files for > all implementations coming from upstreams. That's not correct, we have > nearly none. So we need to generate them our own. And yes this need to > be sent upstream. > > That's the reason for the eclass. > > > That way, you just have to append that path to PKGCONFIG_PATH when > > configuring your package using blas and you should be able to > > transparently select which implementation to get without further > > patching of either upstream or downstream packages. > > > > This would mean that the pkg maintainer decides the implementation. But > we leave this choice to the user which works fine. And we have a working > eselect based solution. No, this means you can then use USE flags to select it which is package manager controlled and usually easier to deal with than eselected stuff. For example, if you know some packages have to be built with the same blas implementation to work properly together, you can do USE deps which is not possible with eselect and I am sure this is not the only case. -- Gilles Dartiguelongue Gentoo
Re: [gentoo-dev] RFC: new eclass - pkgconfig.eclass
On 29/11/12 17:23, hasufell wrote: > On 11/29/2012 03:56 PM, justin wrote: >> On 29/11/12 14:16, hasufell wrote: >>> >>> again, even if there are corner cases which cannot be dealt with >>> in a different way... >>> >>> having an eclass function like the mentioned one is bad, cause >>> it suggests that this is a way to fix things. It's not. >>> Application developers running gentoo might think "oh great, >>> there is a pkgconfig file for this, so I can use it in my >>> Makefile". Then a Fedora packager comes across this package and >>> realizes a compile failure until he notices the build system is >>> calling for a pkgconfig file that cannot be found anywhere. So he >>> contacts this developer and asks which distro he is using. > >> So why not making our lives easier by having a pkg-config option? > > Did you read what you quoted? Are you saying cross distro interfaces > for accessing libraries in build systems are ok to break? > Not only are people using foo.pc to compile a package on gentoo, but > also when writing a build system for "bar" which might link against "foo". > > So having largely unused .pc files is the best case, the worst is > causing random breakage/annoyance for other distros without even > knowing, cause yeah... for us it works. > I understand the pros about pc files and the cons about doing it the way I propose. _But_, there is no cross distro way which we are disturbing. Every distro is having its own magic and naming of those libs. That means, they all patch the buildsystem if needed to use their stuff. The same way as we do since ever. (And I can tell you, for sci package handling blas/lapack is one of the simplest tasks) Our approach is of no interest to 90% or more of the other distros because it would only work on a source distro which has capabilities of selecting different implementations at compile time. And the number of non gentoo derived distros which fullfill this criteria is rather limited. So no general interest of bringing things back upstream. We also do not disturb standard non pm builds as they are normally hardcoding the path to bundled lib or provide a sane autotools/cmake way to point to the lib. And currently all ebuilds in the portage are using pkg-config for a long time, so nothing new here. And nothing non-sci-team members need to worry about. In fact they never did. The only thing what happened was, that I had this crazy idea of writing an eclass to reduce redundant code. This was not about inventing or implementing something new. That has been done a long time before. justin signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: new eclass - pkgconfig.eclass
On 29/11/12 17:54, Gilles Dartiguelongue wrote: > Le jeudi 29 novembre 2012 à 10:07 +0100, justin a écrit : >> On 29/11/12 09:48, Gilles Dartiguelongue wrote: >>> Le jeudi 29 novembre 2012 à 08:52 +0100, justin a écrit : Currently we have an eselect module to switch between different implementations by setting /usr/lib/lib[blas,lapack].so to the selected implementation. This has two drawbacks, which some of you might already of hit: 1. They seem to be not completely API/ABI compatible (I don't which one is correct here. And please don't be nitpicking on this point). So switching would mean recompilation of all packages linked against it before, otherwise you might get runtime errors. This takes time and triggers point 2. 2. As andy showed we should stick with specific implementations for specific tasks. The current way flattens this out to be optimal for some and suboptimal for others. Now, there has been a lot of effort around Andy and Sebastien to solve this problem. The solution is simple: don't install any libblas.so or liblapack.so in libdir, but instead make the pkg-config module eselectable and force packages to used pkg-config. Nearly (I think its 100%) of the packages in the tree already use pkg-config to detect blas/lapack. >>> >>> I think I understand the problem now. You should not patch/generate .pc >>> files but install them to an implementation specific subdirectory. >>> >> >> If I get you correctly you are assuming that we have pkgconfig files for >> all implementations coming from upstreams. That's not correct, we have >> nearly none. So we need to generate them our own. And yes this need to >> be sent upstream. >> >> That's the reason for the eclass. >> >>> That way, you just have to append that path to PKGCONFIG_PATH when >>> configuring your package using blas and you should be able to >>> transparently select which implementation to get without further >>> patching of either upstream or downstream packages. >>> >> >> This would mean that the pkg maintainer decides the implementation. But >> we leave this choice to the user which works fine. And we have a working >> eselect based solution. > > No, this means you can then use USE flags to select it which is package > manager controlled and usually easier to deal with than eselected stuff. > So you mean adding a USE for each implementation to each package which is using one fo blas/cblas/lapack/clapack/lapacke and all the others which I forgot? And in the end, we still would need pc files, because version A of implementation X could have different library names then version B. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: new eclass - pkgconfig.eclass
On 28/11/12 22:49, Justin wrote: > Hi, > > and another one. > > Problem: > Some packages aren't lucky and their buildsystem doesn't create > pkg-config files out of the box. > > Solution: > Create them by hand. > > Eclass: > Simplifies this by providing a general function for that. > > Example: > https://github.com/gentoo-science/sci/blob/pkg-config/sci-libs/mmdb/mmdb-1.24.ebuild > > Thanks for comments, > Justin > So, to end this whole thing here, I pull back my request for integration of this eclass. Thanks for all the comments, critics and suggestions, justin signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Lastrites: net-proxy/paros, net-misc/ups-monitor, app-emulation/mol, net-wireless/fsam7400, net-wireless/acx, net-wireless/acx-firmware, net-wireless/linux-wlan-ng-modules, net-wirele
Walter Dnes schrieb: > Xorg appears to segfault with the xf86-video-modesetting driver. This > includes "Xorg -config". Normally, I run with no xorg.conf, no evdev, > and no udev (I use mdev) and the machine works. I don't know if > they'll accept a bug report due to my non-standard setup. Then try to reproduce the issue in a standard setup. X -configure does not work with KMS. > I did some Google-searching. The vast majority of hits either had > links to https://wiki.archlinux.org/index.php/Poulsbo (the Arch Linux > wiki) or else copied large portions of that page. I followed their > instructions, but it did not help. I'll do some more testing first, to > see if I can narrow down the bug. Other distros invent other names for the X11 drivers (Debian calls it xserver-xorg-video-modesetting and Fedora xorg-x11-drv-modesetting for instance). This may help in finding more information via Google. Best regards, Chí-Thanh Christopher Nguyễn
Re: [gentoo-dev] [PATCH 4/4] Example conversion of pygobject to python-r1 + autotools-utils.
On Thu, 29 Nov 2012 17:50:28 +0100
Gilles Dartiguelongue wrote:
> First, thanks for this patch, I was planning on converting it but did
> not have to do it.
Well, the patch was on the ml a while ago but it was reply to one
of the mails, so it was hard to notice it.
> Le jeudi 29 novembre 2012 à 14:40 +0100, Michał Górny a écrit :
> > ---
> > .../dev-python/pygobject/pygobject-3.2.2-r1.ebuild | 106
> > +
> > 1 file changed, 106 insertions(+)
> > create mode 100644 gx86/dev-python/pygobject/pygobject-3.2.2-r1.ebuild
> >
> > diff --git a/gx86/dev-python/pygobject/pygobject-3.2.2-r1.ebuild
> > b/gx86/dev-python/pygobject/pygobject-3.2.2-r1.ebuild
> > new file mode 100644
> > index 000..289eace
> > --- /dev/null
> > +++ b/gx86/dev-python/pygobject/pygobject-3.2.2-r1.ebuild
> > @@ -0,0 +1,106 @@
> > +# Copyright 1999-2012 Gentoo Foundation
> > +# Distributed under the terms of the GNU General Public License v2
> > +# $Header:
> > /var/cvsroot/gentoo-x86/dev-python/pygobject/pygobject-3.2.2.ebuild,v 1.5
> > 2012/09/28 05:45:45 mattst88 Exp $
> > +
> > +EAPI="4"
> > +GCONF_DEBUG="no"
> > +PYTHON_COMPAT=( python2_6 python2_7 python3_1 python3_2 )
> > +AUTOTOOLS_AUTORECONF=1
> > +
> > +inherit autotools-utils eutils gnome2 python-r1 virtualx
>
> Please do not mix autotools utils with gnome2 eclass. gnome team does
> not support out of tree builds for now. I have plans to integrate this
> in the eclass but we found that upstream generally does not test this so
> we want to test it more extensively before making this available.
Well, the main purpose of this patch was to demonstrate using
out-of-source builds with python-r1.
Therefore, I ask thee: is it acceptable then to use gnome2-utils
in the eclass or shall I restrain completely from using out-of-source
builds on that package?
One thing I can assure you is that this package supports them.
> > +# FIXME: With python multiple ABI support, tests return 1 even when they
> > pass
> > +src_test() {
> > + local DBUS_SESSION_BUS_ADDRESS
> > + local GIO_USE_VFS='local' # prevents odd issues with deleting ${T}/.gvfs
> > + local VIRTUALX_COMMAND=python_test
> > +
> > + export GIO_USE_VFS
> > +
> > + python_foreach_impl virtualmake
> > +
> > + python_execute_function -s testing
> > +}
> > +
> dbus variables needs to be unset for tests to work when you do your
> builds from a terminal started from your desktop, is that really
> equivalent ?
You are correct that it isn't. I wrote the patch before I actually
noticed how crazy local+export logic works. We need to re-export
DBUS_SESSION_BUS_ADDRESS here. Also, I forgot
to remove python_execute_function... silly.
After doing those two changes, the tests succeed for me
with DBUS_SESSION_BUS_ADDRESS set in the parent env.
To be more correct, they succeed for py2.7, 3.1 & 3.2.
In python2.6 they fail with:
@unittest.expectedFailure
AttributeError: 'module' object has no attribute 'expectedFailure'
But that's another story.
I'd say that the ebuild works 100% fine in the version I'm attaching
to this mail.
--
Best regards,
Michał Górny
# Copyright 1999-2012 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header:
/var/cvsroot/gentoo-x86/dev-python/pygobject/pygobject-3.2.2.ebuild,v 1.5
2012/09/28 05:45:45 mattst88 Exp $
EAPI="4"
GCONF_DEBUG="no"
PYTHON_COMPAT=( python2_6 python2_7 python3_1 python3_2 )
AUTOTOOLS_AUTORECONF=1
inherit autotools-utils eutils gnome2 python-r1 virtualx
DESCRIPTION="GLib's GObject library bindings for Python"
HOMEPAGE="http://www.pygtk.org/";
LICENSE="LGPL-2.1+"
SLOT="3"
KEYWORDS="alpha ~amd64 ~arm ~hppa ~ia64 ~mips ~ppc ~ppc64 ~sh ~sparc ~x86
~amd64-fbsd ~x86-fbsd ~x86-interix ~amd64-linux ~x86-linux ~ppc-macos
~x64-macos ~x86-macos ~sparc-solaris ~x64-solaris ~x86-solaris"
IUSE="+cairo examples test +threads" # doc
REQUIRED_USE="test? ( cairo )"
COMMON_DEPEND=">=dev-libs/glib-2.31.0:2
>=dev-libs/gobject-introspection-1.31.20
virtual/libffi
${PYTHON_DEPS}
cairo? ( >=dev-python/pycairo-1.10.0 )"
DEPEND="${COMMON_DEPEND}
test? (
dev-libs/atk[introspection]
media-fonts/font-cursor-misc
media-fonts/font-misc-misc
x11-libs/gdk-pixbuf:2[introspection]
x11-libs/gtk+:3[introspection]
x11-libs/pango[introspection] )
virtual/pkgconfig"
# docs disabled for now per upstream default since they are very out of date
# doc? (
# app-text/docbook-xml-dtd:4.1.2
# dev-libs/libxslt
# >=app-text/docbook-xsl-stylesheets-1.70.1 )
#RESTRICT=test
# We now disable introspection support in slot 2 per upstream recommendation
# (see https://bugzilla.gnome.org/show_bug.cgi?id=642048#c9); however,
# older versions of slot 2 installed their own site-packages/gi, and
# slot 3 will collide with them.
RDEPEND="${COMMON_DEPEND}
!
sign
Re: [gentoo-dev] blas .pc files (was RFC: new eclass - pkgconfig.eclass)
On Thu, 29 Nov 2012 17:09:34 +0100 justin wrote: > On 29/11/12 16:51, Ian Stakenvicius wrote: [...] > > ..ok remind me again what the .pc files provide you? this is so > > that you can have slotted blas providers and various packages can > > choose their preferred one instead of having to use the eselected > > one? or... > > > > Not exactly. > The user can choose for each package newly by eselecting the wanted > implementation. This is the user side. From the pm side we ensure that > the choice is really respected by linking against package specific > names [1] instead of the generic ones e.g. libblas.so. And this can be > achieved in an easy way by using pkg-config. > > justin > > 1) > # eselect blas set atlas-threads > # pkg-config --libs blas > -lptf77blas -lm -latlas -lpthread > > # eselect blas set reference > # pkg-config --libs blas > -lrefblas > This immediately bears the following questions: * How do you ensure the linked against implementation doesn't get depcleaned? revdep-rebuild maybe? * How do you let users configure the implementation to be used on a per package basis? Interrupt an emerge world to set the appropriate implementation for the next few packages? signature.asc Description: PGP signature
Re: [gentoo-dev] blas .pc files (was RFC: new eclass - pkgconfig.eclass)
On 29.11.2012 21:11, Ralph Sennhauser wrote: > On Thu, 29 Nov 2012 17:09:34 +0100 > justin wrote: > >> On 29/11/12 16:51, Ian Stakenvicius wrote: > [...] >>> ..ok remind me again what the .pc files provide you? this is so >>> that you can have slotted blas providers and various packages can >>> choose their preferred one instead of having to use the eselected >>> one? or... >>> >> >> Not exactly. >> The user can choose for each package newly by eselecting the wanted >> implementation. This is the user side. From the pm side we ensure that >> the choice is really respected by linking against package specific >> names [1] instead of the generic ones e.g. libblas.so. And this can be >> achieved in an easy way by using pkg-config. >> >> justin >> >> 1) >> # eselect blas set atlas-threads >> # pkg-config --libs blas >> -lptf77blas -lm -latlas -lpthread >> >> # eselect blas set reference >> # pkg-config --libs blas >> -lrefblas >> > > This immediately bears the following questions: > > * How do you ensure the linked against implementation doesn't get > depcleaned? revdep-rebuild maybe? portage handles this fine. > > * How do you let users configure the implementation to be used on a per > package basis? Interrupt an emerge world to set the appropriate > implementation for the next few packages? > The Standard user will get reference implementation and has no problem. Setting individual implementation on per package basis needs to be considered as they-know-what-they-are-doing. Otherwise you don't know which implementation to choose . signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: RFC: new eclass - pkgconfig.eclass
hasufell posted on Thu, 29 Nov 2012 14:16:18 +0100 as excerpted: > again, even if there are corner cases which cannot be dealt with in a > different way... > > having an eclass function like the mentioned one is bad, cause it > suggests that this is a way to fix things. It's not. Application > developers running gentoo might think "oh great, there is a pkgconfig > file for this, so I can use it in my Makefile". Then a Fedora packager > comes across this package and realizes a compile failure until he > notices the build system is calling for a pkgconfig file that cannot be > found anywhere. So he contacts this developer and asks which distro he > is using. > > This already happened for me multiple times and the answers was > "debian". > > All this sounds like a very dirty workaround and if you need it, then do > it, but _don't_ create an eclass, cause it's not a good thing to > standardize. > These files should _not_ be distro-dependant. Try to find other > solutions. > > -1 for this eclass Suggestion/question for Justin, Mike (Spanky), and others. Assuming people eventually agree that this is a special case, which I'm beginning to think it might be after reading Justin's arguments, tho I recognize that's not a settled case yet... The glibc ebuilds use glibc-specific eblits. This keeps the glibc- specific common code out of the ebuilds (and out of more general purpose eclasses) and in the files dir. Obviously that specific solution won't work for the multiple blas/ whatever packages, since it's single-package/multi-version specific, but is there some variant of it that could work, keeping the code out of eclasses where the not-for-general-purpose solution might be mistakenly thought to be general purpose and get used as such, while still allowing a common to the various *blas/whatever packages solution? The best I can come up with is eblits, thus keeping it out of the individual ebuilds, but forcing the eblits to be copied to all the different implementations individually. Still, that'd save a bit of code between multiple versions of the same package, and a script could be setup that updates all the eblits in the various packages in one go, so it'd be a bit better than having to do it per ebuild. But perhaps someone else can improve on that idea... Another alternative might be an eclass, but name it something like blas- utils or some such, not pkgconfig, thus discouraging inappropriate use, and put in strict warnings and possibly repoman checks, so that only a specific list of packages are allowed to use it. That list could then be controlled by either the science or QA teams as thought appropriate, thus strictly limiting the spread of this ordinarily inappropriate practice. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
Re: [gentoo-dev] Re: RFC: new eclass - pkgconfig.eclass
On 30.11.2012 05:37, Duncan wrote: > hasufell posted on Thu, 29 Nov 2012 14:16:18 +0100 as excerpted: > >> again, even if there are corner cases which cannot be dealt with in a >> different way... >> >> having an eclass function like the mentioned one is bad, cause it >> suggests that this is a way to fix things. It's not. Application >> developers running gentoo might think "oh great, there is a pkgconfig >> file for this, so I can use it in my Makefile". Then a Fedora packager >> comes across this package and realizes a compile failure until he >> notices the build system is calling for a pkgconfig file that cannot be >> found anywhere. So he contacts this developer and asks which distro he >> is using. >> >> This already happened for me multiple times and the answers was >> "debian". >> >> All this sounds like a very dirty workaround and if you need it, then do >> it, but _don't_ create an eclass, cause it's not a good thing to >> standardize. >> These files should _not_ be distro-dependant. Try to find other >> solutions. >> >> -1 for this eclass > > Suggestion/question for Justin, Mike (Spanky), and others. > > Assuming people eventually agree that this is a special case, which I'm > beginning to think it might be after reading Justin's arguments, tho I > recognize that's not a settled case yet... > > The glibc ebuilds use glibc-specific eblits. This keeps the glibc- > specific common code out of the ebuilds (and out of more general purpose > eclasses) and in the files dir. > > Obviously that specific solution won't work for the multiple blas/ > whatever packages, since it's single-package/multi-version specific, but > is there some variant of it that could work, keeping the code out of > eclasses where the not-for-general-purpose solution might be mistakenly > thought to be general purpose and get used as such, while still allowing > a common to the various *blas/whatever packages solution? > > The best I can come up with is eblits, thus keeping it out of the > individual ebuilds, but forcing the eblits to be copied to all the > different implementations individually. Still, that'd save a bit of code > between multiple versions of the same package, and a script could be > setup that updates all the eblits in the various packages in one go, so > it'd be a bit better than having to do it per ebuild. > > But perhaps someone else can improve on that idea... > > Another alternative might be an eclass, but name it something like blas- > utils or some such, not pkgconfig, thus discouraging inappropriate use, > and put in strict warnings and possibly repoman checks, so that only a > specific list of packages are allowed to use it. That list could then be > controlled by either the science or QA teams as thought appropriate, thus > strictly limiting the spread of this ordinarily inappropriate practice. > Thanks for making thoughts about this issue. Meanwhile I talked back to my team lead and he told me that the final solution will be without pc files. This is work in progress, but it will be pc file free and alos not bypassing the buildsystem in anyway. But lets wait. Thanks, Justin signature.asc Description: OpenPGP digital signature
