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
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
impl
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
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
-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 sugg
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 migh
-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
>>
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
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
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,
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 t
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
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
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:
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, split
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.
>
> Resul
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 pac
2012/11/28 Justin :
> 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
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 G
-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://bu
20 matches
Mail list logo
