| 1 |
On Thu, Dec 4, 2008 at 12:29 PM, Diego 'Flameeyes' Pettenò |
| 2 |
<flameeyes@×××××.com> wrote: |
| 3 |
> |
| 4 |
> Since not all the buildsystem we support use make for the actual build, |
| 5 |
> and they don't necessarily support make-like options (-jX -s and so on), |
| 6 |
> it would be nice to be able to express a JOBS variable that could be |
| 7 |
> used for parallel build with any build systems. |
| 8 |
> |
| 9 |
> Right now there are ebuilds like openoffice or some scons-based ebuilds |
| 10 |
> that parse MAKEOPTS and get out of that the number of jobs from the -j |
| 11 |
> option, but this is a) suboptimal b) error-prone. |
| 12 |
> |
| 13 |
> One has to consider people might be using -l for parallel building too, |
| 14 |
> for which reasons I'd be suggesting doing something like this to make |
| 15 |
> the change transparent: |
| 16 |
> |
| 17 |
> - ebuilds using non-make build systems would use JOBS; |
| 18 |
> - ebuilds using make builds systems would just use emake as usual; |
| 19 |
> - Portage takes care, if JOBS is unset, to parse it out of MAKEOPTS; |
| 20 |
> - if user has set JOBS but not MAKEOPTS this defaults to -j${JOBS}; |
| 21 |
> - if user has JOBS and MAKEOPTS, MAKEOPTS keeps the same (for -l). |
| 22 |
> |
| 23 |
> The result is that you can finally combine -l with parallel build on |
| 24 |
> OpenOffice and other packages, with a fallback number of maximum jobs |
| 25 |
> instead of using load-based decisions. |
| 26 |
|
| 27 |
Looks Good To Me, but I would prefix the JOBS variable with some sort |
| 28 |
of namespace (EJOBS, GENTOO_JOBS, etc.) to avoid conflicts with other |
| 29 |
systems that may use JOBS internally already (seems vaguely likely). |
| 30 |
|
| 31 |
-Alec |
| 32 |
|
| 33 |
> |
| 34 |
> -- |
| 35 |
> Diego "Flameeyes" Pettenò |
| 36 |
> http://blog.flameeyes.eu/ |
| 37 |
> |
| 38 |
> |
Archives