[gentoo-dev] RFC: new eclass - pkgconfig.eclass

[gentoo-dev] RFC: new eclass - pkgconfig.eclass

[Justin]

[-- Attachment #1.1: Type: text/plain, Size: 371 bytes --]

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

[-- Attachment #1.2: pkgconfig.eclass --]
[-- Type: text/plain, Size: 5379 bytes --]

# Copyright 1999-2012 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $

# @ECLASS: pkgconfig.eclass
# @MAINTAINER:
# jlec@gentoo.org
# @BLURB: Simplify creation of pkg-config files
# @DESCRIPTION:
# Use this if you buildsystem doesn't create pkg-config files.

inherit multilib

# @ECLASS-VARIABLE: PC_PREFIX
# @REQUIRED
# @DESCRIPTION:
# Offset for current package
: ${PC_PREFIX:="${EPREFIX}/usr"}

# @ECLASS-VARIABLE: PC_EXEC_PREFIX
# @REQUIRED
# @DESCRIPTION:
# Offset for current package
: ${PC_EXEC_PREFIX:="${PC_PREFIX}"}

# @ECLASS-VARIABLE: PC_LIBDIR
# @DESCRIPTION:
# libdir to use
: ${PC_LIBDIR:="${EPREFIX}/usr/$(get_libdir)"}

# @ECLASS-VARIABLE: PC_INCLUDEDIR
# @DESCRIPTION:
# include dir to use
: ${PC_INCLUDEDIR:="${PC_PREFIX}/include"}

# @ECLASS-VARIABLE: PC_NAME
# @DESCRIPTION:
# A human-readable name for the library or package
: ${PC_NAME:=${PN}}

# @ECLASS-VARIABLE: PC_DESCRIPTION
# @DESCRIPTION:
# A brief description of the package
: ${PC_DESCRIPTION:=${DESCRIPTION}}

# @ECLASS-VARIABLE: PC_URL
# @DESCRIPTION:
# An URL where people can get more information about and download the package
: ${PC_URL:=${HOMEPAGE}}

# @ECLASS-VARIABLE: PC_VERSION
# @DESCRIPTION:
# A string specifically defining the version of the package
: ${PC_VERSION:=${PV}}

# @ECLASS-VARIABLE: PC_REQUIRES
# @DEFAULT_UNSET
# @DESCRIPTION:
# A list of packages required by this package. The versions of these packages
# may be specified using the comparison operators =, <, >, <= or >=.

# @ECLASS-VARIABLE: PC_REQUIRES_PRIVATE
# @DEFAULT_UNSET
# @DESCRIPTION:
# A list of private packages required by this package but not exposed to
# applications. The version specific rules from the PC_REQUIRES field also
# apply here.

# @ECLASS-VARIABLE: PC_CONFLICTS
# @DEFAULT_UNSET
# @DESCRIPTION:
# An optional field describing packages that this one conflicts with.
# The version specific rules from the PC_REQUIRES field also apply here.
# This field also takes multiple instances of the same package. E.g.,
# Conflicts: bar < 1.2.3, bar >= 1.3.0.

# @ECLASS-VARIABLE: PC_LIBS
# @DEFAULT_UNSET
# @DESCRIPTION:
# The link flags specific to this package and any required libraries that
# don't support pkg-config. The same rule as PC_CFLAGS applies here.

# @ECLASS-VARIABLE: PC_LIBS_PRIVATE
# @DEFAULT_UNSET
# @DESCRIPTION:
# The link flags for private libraries required by this package but not
# exposed to applications. The same rule as PC_CFLAGS applies here.

# @ECLASS-VARIABLE: PC_CFLAGS
# @DEFAULT_UNSET
# @DESCRIPTION:
# The compiler flags specific to this package and any required libraries
# that don't support pkg-config. If the required libraries support
# pkg-config, they should be added to PC_REQUIRES or PC_REQUIRES_PRIVATE.

# @FUNCTION: create_pkgconfig
# @USAGE: [-p | --prefix PC_PREFIX] [-e | --exec-prefix PC_EXEC_PREFIX] [-L | --libdir PC_LIBDIR ] [-I | --includedir PC_INCLUDEDIR ] [-n | --name PC_NAME] [-d | --description PC_DESCRIPTION] [-V | --version PC_VERSION] [-u | --url PC_URL] [-r | --requires PC_REQUIRES] [--requires-private PC_REQUIRES_PRIVATE] [--conflicts PC_CONFLICTS] [-l | --libs PC_LIBS] [--libs-private PC_LIBS_PRIVATE] [-c | --cflags PC_CFLAGS] <filename>
# @DESCRIPTION:
# Creates and installs .pc file. Function arguments overrule the global set
# eclass variables. The function should only be executed in src_install().
create_pkgconfig() {
	local pcname

	[[ "${EBUILD_PHASE}" != "install" ]] && \
		die "create_pkgconfig should only be used in src_install()"

	while (($#)); do
		case ${1} in
			-p | --prefix )
				shift; PC_PREFIX=${1} ;;
			-e | --exec-prefix )
				shift; PC_EXEC_PREFIX=${1} ;;
			-L | --libdir )
				shift; PC_LIBDIR=${1} ;;
			-I | --includedir )
				shift; PC_INCLUDEDIR=${1} ;;
			-n | --name )
				shift; PC_NAME=${1} ;;
			-d | --description )
				shift; PC_DESCRIPTION=${1} ;;
			-V | --version )
				shift; PC_VERSION=${1} ;;
			-u | --url )
				shift; PC_URL=${1} ;;
			-r | --requires )
				shift; PC_REQUIRES=${1} ;;
			--requires-private )
				shift; PC_REQUIRES_PRIVATE=${1} ;;
			--conflicts )
				shift; PC_CONFLICTS=${1};;
			-l | --libs )
				shift; PC_LIBS=${1} ;;
			--libs-private )
				shift; PC_LIBS_PRIVATE=${1} ;;
			-c | --cflags )
				shift; PC_CFLAGS=${1} ;;
			-* )
				ewarn "Unknown option ${1}" ;;
			* )
				pcname=${1} ;;
		esac
		shift
	done

	[[ -z ${pcname} ]] && die "Missing name for pkg-config file"
	: ${PC_PREFIX:="${EPREFIX}/usr"}
	: ${PC_EXEC_PREFIX:="${PC_PREFIX}"}
	: ${PC_LIBDIR:="${EPREFIX}/usr/$(get_libdir)"}
	: ${PC_INCLUDEDIR:="${PC_PREFIX}/include"}
	: ${PC_NAME:=${PN}}
	: ${PC_DESCRIPTION:=${DESCRIPTION}}
	: ${PC_URL:=${HOMEPAGE}}
	: ${PC_VERSION:=${PV}}

	cat > "${T}"/${pcname}.pc <<- EOF
	prefix="${PC_PREFIX}"
	exec_prefix="${PC_EXEC_PREFIX}"
	libdir="${PC_LIBDIR}"
	includedir="${PC_INCLUDEDIR}"

	Name: ${PC_NAME}
	Description: ${PC_DESCRIPTION}
	Version: ${PC_VERSION}
	URL: ${PC_URL}
	Requires: ${PC_REQUIRES}
	Requires.private: ${PC_REQUIRES_PRIVATE}
	Conflicts: ${PC_CONFLICTS}
	Libs: ${PC_LIBS}
	Libs.private: ${PC_LIBS_PRIVATE}
	Cflags: ${PC_CFLAGS}
	EOF

	insinto /usr/$(get_libdir)/pkgconfig
	doins "${T}"/${pcname}.pc
}

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 261 bytes --]

Re: [gentoo-dev] RFC: new eclass - pkgconfig.eclass

[hasufell]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> create_pkgconfig()

this sounds like a very bad idea.

pkgconfig files are common interfaces and should almost never be
created/modified/renamed anywhere except upstream.

debian packagers are already messing up pkgconfig files randomly
see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=498416 (broke
devilspie2)
also happened for dev-cpp/tbb and a few packages I don't recall right now

The result is that pkgconfig files don't represent common interfaces
anymore, cause application developers can't rely on them being
integrated in different distros in the same way.
Once this evolves further people will stop using them, cause it breaks
build systems.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJQto0zAAoJEFpvPKfnPDWzWJoH/0yCI78/4t/hj/EMCKLGeTh+
LDZDmirdw5dTUpa0ZzG9lu/3GVr3FwwSDc8c+RzQjdRfpA+KwiFs4pEC3zu2CxvG
fwkIkU0g4NUwGF+7cVuqCQ4oAf/05utBFD/lpsWcASA7yB/8PNtT/NHZlsH7VW5v
sZX58bAGrwGcLN2YN5eC+qv+xS9p2ZklG4omBLzG8nc6RAdmLoyuO9fBz4GC+TaV
czTSpdslGnks1Bb+c2i1fuxPVTQTC21X6UQzflQVYh1O1bgOUpmir7kfz5XsEfnT
ZaCO4A0co3r0tK3hxuQk2FoB1z/9+YMquqyPxoblgvB5M3mr5kMHc2IDbGcI/EA=
=ecPj
-----END PGP SIGNATURE-----

Re: [gentoo-dev] RFC: new eclass - pkgconfig.eclass

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 476 bytes --]

On Wed, 28 Nov 2012 22:49:14 +0100
Justin <jlec@gentoo.org> 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.

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]

Re: [gentoo-dev] RFC: new eclass - pkgconfig.eclass

[Christoph Junghans]

2012/11/28 Justin <jlec@gentoo.org>:
> 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
Great jobs, I had a similar eclass on my mind for a long time. It will
for sure be useful for Gentoo prefix builds.

However, I have some suggestions:
- Cflags should contain -I${includedir} and Libs should contain
-L${libdir} by default (see
<http://people.freedesktop.org/~dbn/pkg-config-guide.html#concepts>).
- Reduce the number of global variables. Arguments to create_pkgconfig
are as useful as global variables.
- arguments like -{l,L}* can be used as Libs to avoid redundancy in
the syntax (example: "-lm" instead of "-l -lm"), same for -I*
- it is only one function, maybe it could be added to eutils eclass
- pc files created by this eclass should go into a Gentoo specific
directory (/usr/share/gentoo/lib/pkgconfig?) to avoid confusion with
upstream pc files. This directory can then be added to PKG_CONFIG_PATH
during the build.

Can you also remind me what should go into these private variables and
what not? Since Fedora has started their DSO Linking policy I am very
confused about flags like -lm and -pthreads.

--
Christoph Junghans
http://dev.gentoo.org/~ottxor/

Re: [gentoo-dev] RFC: new eclass - pkgconfig.eclass

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 486 bytes --]

On Wednesday 28 November 2012 16:49:14 Justin wrote:
> Problem:
> Some packages aren't lucky and their buildsystem doesn't create
> pkg-config files out of the box.
> 
> Solution:
> Create them by hand.

i agree this is a problem.  but i think the only real place to fix this is in 
the upstream package.  otherwise, the .pc file is largely unused and kind of 
pointless.  other people have already enumerated more detailed responses, so 
i'll just leave it at this.
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] RFC: new eclass - pkgconfig.eclass

[Richard Yao]

[-- Attachment #1: Type: text/plain, Size: 685 bytes --]

On 11/28/2012 05:21 PM, Michał Górny wrote:
> On Wed, 28 Nov 2012 22:49:14 +0100
> Justin <jlec@gentoo.org> 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.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 900 bytes --]

[gentoo-dev] Re: RFC: new eclass - pkgconfig.eclass

[Duncan]

Richard Yao posted on Wed, 28 Nov 2012 20:26:00 -0500 as excerpted:

> On 11/28/2012 05:21 PM, Michał Górny wrote:
>> On Wed, 28 Nov 2012 22:49:14 +0100 Justin <jlec@gentoo.org> 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.

You missed the point.  This has nothing to do with the usual -dev 
packages on binary distros.

If the upstream devs for a package, call it package A, depending on and 
using a library, call it library B, are on gentoo, and gentoo's creating 
the *.pc files for library B because its upstream doesn't, then the devs 
of package A, being on gentoo, won't be aware that the upstream library B 
doesn't provide the *.pc files, since they're there on a gentoo system, 
because gentoo's providing them.

So the package A developer (on gentoo) will depend on library B's *.pc 
file, wrongly believing it's provided by upstream, when it's not, thus 
screwing up things for all the OTHER distros when they try to build 
package A, because it's trying to use a non-existent *.pc file that 
library B should have provided, but didn't.

The only proper way to fix it, therefore, is to persuade upstream to 
include the *.pc file, NOT for gentoo to provide what upstream should be 
shipping, but isn't.

-- 
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] RFC: new eclass - pkgconfig.eclass

[Chí-Thanh Christopher Nguyễn]

hasufell schrieb:
>> create_pkgconfig()
> 
> this sounds like a very bad idea.
> 
> pkgconfig files are common interfaces and should almost never be 
> created/modified/renamed anywhere except upstream.

X11 team considered doing exactly that once after the nouveau API break in
libdrm-2.4.33, splitting libdrm_nouveau-2.4.32 into its own separate
package and renaming/modifying libdrm_nouveau.pc to make it installable in
parallel to more recent libdrm[video_cards_nouveau] (bug 409593 comment
30). We ultimately decided against it though.


Best regards,
Chí-Thanh Christopher Nguyễn

Re: [gentoo-dev] RFC: new eclass - pkgconfig.eclass

[Rémi Cardona]

Le mercredi 28 novembre 2012 à 22:49 +0100, Justin a écrit :
> Solution:
> Create them by hand.

The solution is to tell *upstream* how to build and ship .pc files with
their build system.

If we start shipping .pc files no one else has, projects that use such
libraries will have only 2 choices:

 - check the .pc file and use whatever fallback code they had before to
find the correct library paths and options.
 - change nothing and keep their current code

Either way, we'll be stuck maintaining .pc files no one will be using.

Please convince upstreams stuck in the middle ages that .pc files are a
Good Thing™ that make everybody's lives easier.

Cheers,

Rémi

Re: [gentoo-dev] RFC: new eclass - pkgconfig.eclass

[justin]

[-- Attachment #1: Type: text/plain, Size: 3509 bytes --]

On 29/11/12 02:14, Mike Frysinger wrote:
> On Wednesday 28 November 2012 16:49:14 Justin wrote:
>> Problem:
>> Some packages aren't lucky and their buildsystem doesn't create
>> pkg-config files out of the box.
>>
>> Solution:
>> Create them by hand.
> 
> i agree this is a problem.  but i think the only real place to fix this is in 
> the upstream package.  otherwise, the .pc file is largely unused and kind of 
> pointless.  other people have already enumerated more detailed responses, so 
> i'll just leave it at this.
> -mike
> 

Hi,

I will respond here, but this also is addressed to all the other
negative responses.

Let me explain the reason we (sci team) are using manually created .pc
files. And as a side note I totally agree with the statement that pc
file creation should be upstreams business.

Back to the problem. We are mainly using this approach to allow multiple
installations of packages providing BLAS and LAPACK implementations, and
its derivative. Why this? There is a reference implementation, a closed
source intel implementation, optimized versions for speed, a gnu version
and so on, from which the user should be able to choose. Still why we
need a switchable system? I would like to point [1] you to some great
GSOC work from andy which he also present in Praque [2]. He clearly
showed, that different implementations are good for different puposes.
Therefore we need to have different implementations installed in parallel.

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.

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,

justin


1)
https://github.com/andyspiros/numbench/wiki
http://andyspiros.wordpress.com/category/google-summer-of-code/

2)
http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo/xml/htdocs/proj/en/miniconf/presentations/miniconf-2012-numbench-spiros.pdf


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 261 bytes --]

Re: [gentoo-dev] RFC: new eclass - pkgconfig.eclass

[Gilles Dartiguelongue]

[-- Attachment #1: Type: text/plain, Size: 1610 bytes --]

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 <eva@gentoo.org>
Gentoo

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] RFC: new eclass - pkgconfig.eclass

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1277 bytes --]

On Thu, 29 Nov 2012 08:52:01 +0100
justin <jlec@gentoo.org> 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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]

Re: [gentoo-dev] RFC: new eclass - pkgconfig.eclass

[justin]

[-- Attachment #1: Type: text/plain, Size: 2108 bytes --]

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 261 bytes --]

Re: [gentoo-dev] RFC: new eclass - pkgconfig.eclass

[justin]

[-- Attachment #1: Type: text/plain, Size: 2856 bytes --]

On 29/11/12 09:52, Michał Górny wrote:
> On Thu, 29 Nov 2012 08:52:01 +0100
> justin <jlec@gentoo.org> 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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 261 bytes --]

Re: [gentoo-dev] RFC: new eclass - pkgconfig.eclass

[hasufell]

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

[Ian Stakenvicius]

-----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 <jlec@gentoo.org>
>> 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-----

Re: [gentoo-dev] RFC: new eclass - pkgconfig.eclass

[justin]

[-- Attachment #1: Type: text/plain, Size: 1133 bytes --]

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 261 bytes --]

Re: [gentoo-dev] blas .pc files (was RFC: new eclass - pkgconfig.eclass)

[Ian Stakenvicius]

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

[justin]

[-- Attachment #1: Type: text/plain, Size: 1386 bytes --]

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



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 261 bytes --]

Re: [gentoo-dev] RFC: new eclass - pkgconfig.eclass

[hasufell]

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

[hasufell]

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

[Ian Stakenvicius]

-----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] RFC: new eclass - pkgconfig.eclass

[Gilles Dartiguelongue]

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 <eva@gentoo.org>
Gentoo

Re: [gentoo-dev] RFC: new eclass - pkgconfig.eclass

[justin]

[-- Attachment #1: Type: text/plain, Size: 2639 bytes --]

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



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 261 bytes --]

Re: [gentoo-dev] RFC: new eclass - pkgconfig.eclass

[justin]

[-- Attachment #1: Type: text/plain, Size: 2767 bytes --]

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.




[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 261 bytes --]

Re: [gentoo-dev] RFC: new eclass - pkgconfig.eclass

[justin]

[-- Attachment #1: Type: text/plain, Size: 612 bytes --]

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 261 bytes --]

Re: [gentoo-dev] blas .pc files (was RFC: new eclass - pkgconfig.eclass)

[Ralph Sennhauser]

[-- Attachment #1: Type: text/plain, Size: 1262 bytes --]

On Thu, 29 Nov 2012 17:09:34 +0100
justin <jlec@gentoo.org> 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?

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] blas .pc files (was RFC: new eclass - pkgconfig.eclass)

[Justin]

[-- Attachment #1: Type: text/plain, Size: 1634 bytes --]

On 29.11.2012 21:11, Ralph Sennhauser wrote:
> On Thu, 29 Nov 2012 17:09:34 +0100
> justin <jlec@gentoo.org> 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 .


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 261 bytes --]

[gentoo-dev] Re: RFC: new eclass - pkgconfig.eclass

[Duncan]

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

[Justin]

[-- Attachment #1: Type: text/plain, Size: 3237 bytes --]

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 261 bytes --]

Re: [gentoo-dev] Re: RFC: new eclass - pkgconfig.eclass

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 934 bytes --]

On Thursday 29 November 2012 23:37:18 Duncan wrote:
> 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?

since it's specific to the sci case, i wouldn't be against keeping it in the 
sci eclasses.  the current situation as outlined by Justin sucks either way 
(not saying it's sci teams fault, just that it's a pita situation to deal 
with).

what is a problem is adding a generic "pkgconfig.eclass".  that encourages 
other people to add it to their own random packages since it 
looks/sounds/tastes like a generic & encouraged solution.
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]