| 1 |
On Wed, 13 Jun 2012 11:16:45 +0200 |
| 2 |
Dirkjan Ochtman <djc@g.o> wrote: |
| 3 |
|
| 4 |
> Additionally, the new eclass seems to think of pypy1_7, pypy1_8 as |
| 5 |
> different. We should probably have something that says, "this ebuild |
| 6 |
> supports python-2.7-equivalent pypy". |
| 7 |
|
| 8 |
Are they equivalent API-wise? In other words, is it guaranteed that if |
| 9 |
a particular Python extension (written in C) compiles with 1.8, it will |
| 10 |
compile with 1.7 and vice-versa? |
| 11 |
|
| 12 |
> Proposal: |
| 13 |
> |
| 14 |
> - Add python2_7_pypy atom for PYTHON_COMPAT, expands to a list of pypy |
| 15 |
> versions which is fixed in the eclass. |
| 16 |
|
| 17 |
Maybe we could just assume pypy1_7 means 1.7+ but older than next |
| 18 |
pypy1_x defined. |
| 19 |
|
| 20 |
-- |
| 21 |
Best regards, |
| 22 |
Michał Górny |
Archives