| 1 |
On Thu, Jul 19, 2018 at 10:14 AM, Michał Górny <mgorny@g.o> wrote: |
| 2 |
> W dniu czw, 19.07.2018 o godzinie 10∶06 -0400, użytkownik Mike Gilbert |
| 3 |
> napisał: |
| 4 |
>> On Tue, Jul 17, 2018 at 10:48 AM, Michał Górny <mgorny@g.o> wrote: |
| 5 |
>> > W dniu wto, 17.07.2018 o godzinie 10∶40 -0400, użytkownik Mike Gilbert |
| 6 |
>> > napisał: |
| 7 |
>> > > On Tue, Jul 17, 2018 at 4:41 AM, Michał Górny <mgorny@g.o> wrote: |
| 8 |
>> > > > Python 3.5+ introduces parallel build support in distutils. Take |
| 9 |
>> > > > advantage of that by passing appropriate -j option. Since distutils |
| 10 |
>> > > > does not support an equivalent of --load-average, default to the number |
| 11 |
>> > > > of CPUs+1 when unspecified. |
| 12 |
>> > > |
| 13 |
>> > > How do we disable this in individual ebuilds when we inevitably run |
| 14 |
>> > > into problematic packages? |
| 15 |
>> > |
| 16 |
>> > My guess would be, same as emake: |
| 17 |
>> > |
| 18 |
>> > distutils-r1_python_compile -j1 |
| 19 |
>> > |
| 20 |
>> > (I haven't tested it though) |
| 21 |
>> |
| 22 |
>> This will affect stable ebuilds that have python3_5 or python3_6 |
| 23 |
>> enabled. It would be a good idea to test it on a reasonable sample of |
| 24 |
>> ebuilds first. |
| 25 |
>> |
| 26 |
>> Alternatively, we could enable it for python3_7 first and see what |
| 27 |
>> kind of fallout that produces. |
| 28 |
>> |
| 29 |
> |
| 30 |
> Given that we still have a reasonably small set of EAPI 7 ebuilds, how |
| 31 |
> about EAPI 7 for all Pythons + python3_7 for all EAPIs? ;-) |
| 32 |
|
| 33 |
That sounds good to me. |
Archives