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] 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] blas .pc files (was RFC: new eclass - pkgconfig.eclass)
On Thu, 29 Nov 2012 17:09:34 +0100 justin j...@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? 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 j...@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 . signature.asc Description: OpenPGP digital signature
