| 1 |
On Thursday 29 November 2012 23:37:18 Duncan wrote: |
| 2 |
> Obviously that specific solution won't work for the multiple blas/ |
| 3 |
> whatever packages, since it's single-package/multi-version specific, but |
| 4 |
> is there some variant of it that could work, keeping the code out of |
| 5 |
> eclasses where the not-for-general-purpose solution might be mistakenly |
| 6 |
> thought to be general purpose and get used as such, while still allowing |
| 7 |
> a common to the various *blas/whatever packages solution? |
| 8 |
|
| 9 |
since it's specific to the sci case, i wouldn't be against keeping it in the |
| 10 |
sci eclasses. the current situation as outlined by Justin sucks either way |
| 11 |
(not saying it's sci teams fault, just that it's a pita situation to deal |
| 12 |
with). |
| 13 |
|
| 14 |
what is a problem is adding a generic "pkgconfig.eclass". that encourages |
| 15 |
other people to add it to their own random packages since it |
| 16 |
looks/sounds/tastes like a generic & encouraged solution. |
| 17 |
-mike |
Archives