1 |
Diego 'Flameeyes' =?utf-8?Q?Petten=C3=B2?= wrote: |
2 |
|
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 |
Sounds good for me. |
28 |
What do you do for other build systems which also decide on load-basis |
29 |
how many jobs to run? Parse again? |
30 |
In that case I'd like to see a more abstract definition of "how many |
31 |
jobs to run in parallel" which gets translated to the correct |
32 |
make-options for emake and which is query'able either via a variable or |
33 |
a function (something like JOBS="load=0.7||max=3" maybe?). |