| 1 |
On Tue, 2015-12-01 at 18:45 +0100, Michał Górny wrote: |
| 2 |
> On Tue, 1 Dec 2015 11:38:08 -0600 |
| 3 |
> William Hubbs <williamh@g.o> wrote: |
| 4 |
> |
| 5 |
> > I find the multilib eclasses and their separate multilib phase |
| 6 |
> > functions |
| 7 |
> > to be confusing, so I was wondering if we could discuss making |
| 8 |
> > multilib |
| 9 |
> > support native to portage in eapi 7 so that we can use the normal |
| 10 |
> > phase |
| 11 |
> > functions again? |
| 12 |
> |
| 13 |
> That won't help you since the in-spec support would require special |
| 14 |
> phase functions anyway. |
| 15 |
|
| 16 |
It might help with other things, though. I think it might be hard to |
| 17 |
build sufficient consensus around this, but, if we could do so, it |
| 18 |
could really be a boon. |
| 19 |
|
| 20 |
As I recently pointed out in another thread, if we had a really easy- |
| 21 |
to-use, high-performing dedicated vdb feature behind "multi-ness," we |
| 22 |
might realize all kinds of benefits. |
| 23 |
|
| 24 |
For example -- of course the following are hoplessly speculative but |
| 25 |
just humor me for a moment -- in a sufficiently flexible |
| 26 |
implementation, concievably things like prefix and crossdev could be |
| 27 |
normalized as, respectively, user-configurable "EPREFIX" and "target" |
| 28 |
"multi-" dimensions. |
| 29 |
|
| 30 |
Not saying they should be, though, just making the point that the |
| 31 |
concievable applications of a feature tend to correspond to the |
| 32 |
feature's limitations and strengths from a practical perspective, and |
| 33 |
our current multi- eclass frameworks are fairly limited in precisely |
| 34 |
that way, despite being tremendously clever solutions to a very |
| 35 |
difficult problem. |
| 36 |
|
| 37 |
-gmt |
Archives