| Summary: | dev-libs/boost-1.35.0-r5 does not emerge when MAKEOPTS="--jobs --load-average=3" | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | mehrunes <mehrunes_dagon> |
| Component: | [OLD] Development | Assignee: | C++ Team [disbanded] <cpp+disabled> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | cpp+disabled |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: |
emerge --info output
unsuccessful emerge log |
||
|
Description
mehrunes
2010-03-03 04:45:16 UTC
Created attachment 221901 [details]
emerge --info output
Created attachment 221903 [details]
unsuccessful emerge log
with my MAKEOPTS bjam-1_35 gets command-line options -j --load-average=3 could this be the reason for the eternal sleep? Boost ebuild does some magic to figure out number of jobs to run with, as it doesn't use makefiles, so MAKEOPTS isn't picked up. The algo used somewhat evolved in more recent versions, but doesn't seem to be backported. (In reply to comment #4) > Boost ebuild does some magic to figure out number of jobs to run with, as it > doesn't use makefiles, so MAKEOPTS isn't picked up. The algo used somewhat > evolved in more recent versions, but doesn't seem to be backported. > i did not say that bjam checks for MAKEOPTS in my post no.3 i meant to say that with my value of MAKEOPTS ebuild gives bjam command-line options -j --load-average=3 and my question was whether these options are valid > i did not say that bjam checks for MAKEOPTS I didn't say that either. > in my post no.3 i meant to say that with my value of MAKEOPTS ebuild gives bjam > command-line options Ebuild isn't giving bjam your MAKEOPTS. It's trying to find out number of jobs by looking at it and then uses it with bjam. Fact that bjam and make use '-j N' to denote number of jobs to run in parallel is a pure coincidence. > -j --load-average=3 > > and my question was whether these options are valid Hack used in 1.35 possibly does not catch that case so no. This _should_ be fixed now. |