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 B21EA1381F3 for ; Sat, 25 May 2013 19:45:17 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 126D8E0BDA; Sat, 25 May 2013 19:45:12 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 1AE45E0BC4 for ; Sat, 25 May 2013 19:45:11 +0000 (UTC) Received: from [192.168.1.204] (76-230-137-203.lightspeed.livnmi.sbcglobal.net [76.230.137.203]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: floppym) by smtp.gentoo.org (Postfix) with ESMTPSA id 223BA33DF65 for ; Sat, 25 May 2013 19:45:10 +0000 (UTC) Message-ID: <51A114C2.5070306@gentoo.org> Date: Sat, 25 May 2013 15:45:06 -0400 From: Mike Gilbert User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130520 Thunderbird/17.0.6 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 To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Usage of dev-utils/ninja in ebuilds References: <51A1077E.1030607@gentoo.org> <20130525211750.61b81a57@TOMWIJ-GENTOO> In-Reply-To: <20130525211750.61b81a57@TOMWIJ-GENTOO> X-Enigmail-Version: 1.6a1pre Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="----enig2VCRKAVARBELGQMCQXUNL" X-Archives-Salt: c42118c7-d7eb-4b73-8f33-3dbe214f078b X-Archives-Hash: 692d0439fe535365e6f6f08530f24a87 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2VCRKAVARBELGQMCQXUNL Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 05/25/2013 03:17 PM, Tom Wijsman wrote: > From an user perspective I was wondering if ninja in the Portage tree > makes use of this faster incremental builds feature. Should I expect > faster builds when trying this out? >=20 No, you will not see any significant speed increase because we always start with an empty build directory in an ebuild. Nothing has changed in that regard. You may see small (~60 seconds) difference when compiling Chromium due to faster target dependency resolution. > From a maintainer's perspective, shouldn't the user be able to choose > whether ninja or make is used and not the developer? Or does ninja > really work out for the majority in a way nobody would complain? >=20 As a maintainer, it is nice to know exactly how the software is being built in case of a bug report. This also helps if we need to report an issue upstream. I should clarify: ninja is not a *drop-in* replacement for make; it does not parse Makefiles. Instead, it uses its own configuration format, which may be generated using GYP or CMake. The choice of build system should be transparent to the user. However, I have no strong personal objection to making it configurable. > From an upstream perspective, would it be problematic if people use > make instead of ninja; or wouldn't it translate into problems upstream > has to resolve? (To me, using ninja instead of make sounds like using > llvm instead of gcc; correct me if I'm wrong, I'm fairly new to ninja.)= >=20 So long as GYP supports emitting makefiles as well as ninja build files, I don't think this will be a problem. For Gentoo, I believe phajdan.jr simply chose to switch to ninja to more closely mimic the normal upstream build process. >> I'm wondering if we should create a more global function for calling >> ninja in a consistent way. Maybe we should introduce a NINJAOPTS >> variable for users to set in make.conf. Should we create a new eclass >> for this, or just stick it in eutils? >=20 > If we don't allow the user to pick which make system is preferred, > which I tried to suggest above; then I would prefer that we introduce > a NINJAOPTS variable like you suggest to go alongside MAKEOPTS. >=20 > In the case the user is able to choose which make system is preferred, > then MAKEOPTS should probably apply to that make system; unless we allo= w > maintainer's to override the user, then splitting them is back in favor= =2E >=20 Another thought would be to mimic scons-utils.eclass, which utilizes a filtered copy of MAKEOPTS if SCONSOPTS is not defined. > But well, this is based on preliminary thoughts without really > properly knowing what the advantages and disadvantages here are. >=20 I believe the only real advantage to using ninja for building chromium is to follow upstream's default build configuration. It should be pretty transparent to the end user. ------enig2VCRKAVARBELGQMCQXUNL Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iF4EAREIAAYFAlGhFMIACgkQC77qH+pIQ6S/KgD/YrOUTPeu0HOAKB0xeKLM5IgJ sBrEYIVMzKWDg3abuDMBAJhD3ns9gmKSYx2zvrRnakrBs8QlOBLCNT9M9PkrlVXm =wJ2a -----END PGP SIGNATURE----- ------enig2VCRKAVARBELGQMCQXUNL--