1 |
>>>>> On Thu, 4 Dec 2008, Diego 'Flameeyes' Pettenò wrote: |
2 |
|
3 |
> Since not all the buildsystem we support use make for the actual |
4 |
> build, and they don't necessarily support make-like options (-jX -s |
5 |
> and so on), it would be nice to be able to express a JOBS variable |
6 |
> that could be used for parallel build with any build systems. |
7 |
|
8 |
> Right now there are ebuilds like openoffice or some scons-based |
9 |
> ebuilds that parse MAKEOPTS and get out of that the number of jobs |
10 |
> from the -j option, but this is a) suboptimal b) error-prone. |
11 |
|
12 |
> One has to consider people might be using -l for parallel building |
13 |
> too, for which reasons I'd be suggesting doing something like this to |
14 |
> make the change transparent: |
15 |
|
16 |
> - ebuilds using non-make build systems would use JOBS; |
17 |
> - ebuilds using make builds systems would just use emake as usual; |
18 |
> - Portage takes care, if JOBS is unset, to parse it out of MAKEOPTS; |
19 |
> - if user has set JOBS but not MAKEOPTS this defaults to -j${JOBS}; |
20 |
> - if user has JOBS and MAKEOPTS, MAKEOPTS keeps the same (for -l). |
21 |
|
22 |
> The result is that you can finally combine -l with parallel build on |
23 |
> OpenOffice and other packages, with a fallback number of maximum jobs |
24 |
> instead of using load-based decisions. |
25 |
|
26 |
Coming back to this old topic [1]. Is there still consensus that we |
27 |
should have such an EJOBS variable? (It shouldn't be called JOBS because |
28 |
this name is too generic, see the old discussion.) Then we could add it |
29 |
to EAPI 5. |
30 |
|
31 |
Ulrich |
32 |
|
33 |
[1] <http://archives.gentoo.org/gentoo-dev/msg_750e33f68b16d971dff1f40dd9145e56.xml> |