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
