From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 179F1138010 for ; Fri, 31 Aug 2012 15:13:58 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id AC54BE0605; Fri, 31 Aug 2012 15:13:39 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id 51A69E04EC for ; Fri, 31 Aug 2012 15:12:55 +0000 (UTC) Received: from localhost (unknown [200.89.69.133]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: aballier) by smtp.gentoo.org (Postfix) with ESMTPSA id AAEFD33D825 for ; Fri, 31 Aug 2012 15:12:53 +0000 (UTC) Date: Fri, 31 Aug 2012 11:12:44 -0400 From: Alexis Ballier To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] EJOBS variable for EAPI 5? (was: [RFC] Create a JOBS variable to replace -jX in MAKEOPTS) Message-ID: <20120831111244.0c17b8aa@gentoo.org> In-Reply-To: <20120831154521.5258c549@googlemail.com> References: <20544.29691.208130.35494@a1i15.kph.uni-mainz.de> <20120831154521.5258c549@googlemail.com> Organization: Gentoo X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.11; x86_64-pc-linux-gnu) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Archives-Salt: 4b8b7dd6-4b4f-43f6-824e-2d5dca77ce4e X-Archives-Hash: 21faae499e879d052040a36907f4ce53 On Fri, 31 Aug 2012 15:45:21 +0100 Ciaran McCreesh wrote: > On Fri, 31 Aug 2012 10:21:15 +0200 > Ulrich Mueller wrote: > > Coming back to this old topic [1]. Is there still consensus that we > > should have such an EJOBS variable? (It shouldn't be called JOBS > > because this name is too generic, see the old discussion.) Then we > > could add it to EAPI 5. > > > > Ulrich > > > > [1] > > > > If we're doing this, do we tell users to stop setting MAKEOPTS for > EAPIs 5 and greater? How can this work ? I cant think of any simple solution. > Do we change the name of MAKEOPTS for EAPIs 5 and > greater instead? Do we put fancy code in the package mangler to deal > with it? IMHO EAPI-5 compliant PMs should do MAKEOPTS="$MAKEOPTS -j$EJOBS" for every EAPI; using EJOBS from ebuilds/eclasses is allowed only in EAPI 5 and greater. This is retroactive but could be classified 'PM internals' so its fine imho. People using such a PM and not reading the news will get the old MAKEOPTS which will still work with makefile based build systems but will get serial builds for e.g. EAPI5 ebuilds + waf based build systems. Not a very big deal. A.