| 1 |
On Mon, Dec 8, 2014 at 12:08 PM, Matt Turner <mattst88@g.o> wrote: |
| 2 |
> eclasses are pretty great for sharing code akin to a library, but when |
| 3 |
> *all* of your ebuild's logic is in the eclass, well, that's not really |
| 4 |
> the intended use case as far as I can tell. |
| 5 |
|
| 6 |
It works well in cases like KDE where you have 300 ebuilds that all |
| 7 |
just set a few environment variables and then genuinely share common |
| 8 |
code for everything else. Also, major updates only come once every |
| 9 |
few years, which helps keep the eclass from becoming a rat's nest. I |
| 10 |
think it is better to just version an eclass instead of having a mess |
| 11 |
of conditionals based on version, but then we'd have 300 revisions of |
| 12 |
toolchain.eclass (which is probably a good hint that we're doing it |
| 13 |
wrong). |
| 14 |
|
| 15 |
A library is a good analogy of how to avoid all of this. Each |
| 16 |
function does one thing well, and you call them as you need them, and |
| 17 |
you don't tweak their APIs 10 times per year. And if you find you're |
| 18 |
never using a function more than once after doing this, then you don't |
| 19 |
need a library in the first place. |
| 20 |
|
| 21 |
-- |
| 22 |
Rich |
Archives