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

[justin]

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