Gentoo Archives: gentoo-user

From: Rich Freeman <rich0@g.o>
To: gentoo-user@l.g.o
Subject: Re: [gentoo-user] "emerge --jobs=1 ..." vs "MAKEOPTS=-j1 emerge ..."
Date: Sun, 21 Jun 2020 10:20:52
Message-Id: CAGfcS_k8Vf29DGOiBU0UBwX+=JA96a0Qk8Q0w5zETxtf7oyGZA@mail.gmail.com
In Reply to: [gentoo-user] "emerge --jobs=1 ..." vs "MAKEOPTS=-j1 emerge ..." by Dr Rainer Woitok
1 On Sun, Jun 21, 2020 at 5:53 AM Dr Rainer Woitok
2 <rainer.woitok@×××××.com> wrote:
3 >
4 > is there any difference between running "emerge --jobs=1 ..." and runn-
5 > ing "MAKEOPTS=-j1 emerge ..."?
6 >
7
8 Yes.
9
10 --jobs=1 tells emerge to build one package at a time.
11
12 -j1 tells make to compile one file at a time when building a package.
13
14 So, if you have 10 independent packages containing 10 independent C
15 files, --jobs=10 and -j10 will build all 100 C files in parallel.
16 --jobs=1 and -j10 will build each package in series, with all 10 C
17 files in each package in parallel. --jobs=10 and -j1 will build all
18 10 packages in parallel, but each one will build one C file at a time.
19
20 If you have the cores to spare each is useful, because rarely are
21 either packages or the files within them completely independent. So
22 running both in parallel maximizes the opportunity to keep your cores
23 busy, of course at the cost of memory if you spawn too many. It is
24 hard to perfectly predict the optimal combination since portage can't
25 tell how parallel any particular package is.
26
27 Setting -j1 is necessary in some build systems due to bugs in the
28 dependency expressions inside them. This SHOULD be done by packages
29 automatically, but sometimes it is missed. Bugs should be filed in
30 these cases to get the ebuilds fixed, but in the meantime setting -j1
31 can fix this. (This was recently discussed on this list for that pam
32 dependency - which has already been fixed in the repo so you don't
33 actually need to worry about it now.) It shouldn't really be
34 necessary to set --jobs=1 unless you're running out of RAM, because it
35 is pretty rare to have portage dependency issues and if you do chances
36 are the package will break either way (because the unspecified
37 dependency just won't be built at all - unlike with make where
38 generally everything does get built just in the wrong order).
39
40 Hopefully this helps...
41
42 --
43 Rich