From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id CB01D1382C5 for ; Sun, 21 Jun 2020 10:20:52 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id AD183E08AD; Sun, 21 Jun 2020 10:20:47 +0000 (UTC) Received: from mail-ed1-f67.google.com (mail-ed1-f67.google.com [209.85.208.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 6FB1CE087B for ; Sun, 21 Jun 2020 10:20:47 +0000 (UTC) Received: by mail-ed1-f67.google.com with SMTP id cy7so4728746edb.5 for ; Sun, 21 Jun 2020 03:20:47 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=mpXEAI6BpE+vUSnC59X/ROevTjhIlwh4LJsIk1r0mus=; b=Jc8M2nMLpHeRs6uTUYNTz2ynnXT9kgyOGWCQJ7X8Gup0SH+O5KqEgBIW8s1dKM+BY4 FvCAJkj9/JRuwrq1Cz2FBPsBy6fyqZbqVpwCjPgEhoApVHcDMxZLzfIZFwonbOujT4G4 sNBvBIbp1uR0eoxD0lnNs1Vu8BMGF0tUPKgfmikk0cZ+as41xmYn6udpvVmaJ6aSfKjt qotN6RvucPGxHDn44BOTbor/kMbF7SOgftFk4t5uRz01U6n92Mjy3uZhvmoCEc5DEgbn NogXeE4xc1T9OCCVBpZz7e8KNq3qk0dwLHx2+yTl43SJ1dk9FY7KipurY/dMVtOatm+D YaxA== X-Gm-Message-State: AOAM531qV1s/v7Er8bHFuj3Mb4na0Q9cUI5tLvef98nh97xF+5rm9u9v //g+6rB3d+569oqUX1FxwBZt7/dlXbpYhK++umGdYQ== X-Google-Smtp-Source: ABdhPJxcpLAz1mKkEmNfhIb50ScS1uJPqnPw1DvQgzNZwg6b2DA7hEQ2mb6qqj1nS34T2h3qQrFpamuwScMedoA2xDU= X-Received: by 2002:aa7:d2d2:: with SMTP id k18mr4749173edr.16.1592734845850; Sun, 21 Jun 2020 03:20:45 -0700 (PDT) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply MIME-Version: 1.0 References: <24303.11806.371890.563490@tux.local> In-Reply-To: <24303.11806.371890.563490@tux.local> From: Rich Freeman Date: Sun, 21 Jun 2020 06:20:33 -0400 Message-ID: Subject: Re: [gentoo-user] "emerge --jobs=1 ..." vs "MAKEOPTS=-j1 emerge ..." To: gentoo-user@lists.gentoo.org Content-Type: text/plain; charset="UTF-8" X-Archives-Salt: d9dfca49-29f2-4e4f-9321-95cb1d689f56 X-Archives-Hash: dca52aa27586269e7fc20834196e21be On Sun, Jun 21, 2020 at 5:53 AM Dr Rainer Woitok wrote: > > is there any difference between running "emerge --jobs=1 ..." and runn- > ing "MAKEOPTS=-j1 emerge ..."? > Yes. --jobs=1 tells emerge to build one package at a time. -j1 tells make to compile one file at a time when building a package. So, if you have 10 independent packages containing 10 independent C files, --jobs=10 and -j10 will build all 100 C files in parallel. --jobs=1 and -j10 will build each package in series, with all 10 C files in each package in parallel. --jobs=10 and -j1 will build all 10 packages in parallel, but each one will build one C file at a time. If you have the cores to spare each is useful, because rarely are either packages or the files within them completely independent. So running both in parallel maximizes the opportunity to keep your cores busy, of course at the cost of memory if you spawn too many. It is hard to perfectly predict the optimal combination since portage can't tell how parallel any particular package is. Setting -j1 is necessary in some build systems due to bugs in the dependency expressions inside them. This SHOULD be done by packages automatically, but sometimes it is missed. Bugs should be filed in these cases to get the ebuilds fixed, but in the meantime setting -j1 can fix this. (This was recently discussed on this list for that pam dependency - which has already been fixed in the repo so you don't actually need to worry about it now.) It shouldn't really be necessary to set --jobs=1 unless you're running out of RAM, because it is pretty rare to have portage dependency issues and if you do chances are the package will break either way (because the unspecified dependency just won't be built at all - unlike with make where generally everything does get built just in the wrong order). Hopefully this helps... -- Rich