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