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 B623A1381F3 for ; Sat, 25 May 2013 19:20:04 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id B0847E0BB9; Sat, 25 May 2013 19:19:56 +0000 (UTC) Received: from georges.telenet-ops.be (georges.telenet-ops.be [195.130.137.68]) by pigeon.gentoo.org (Postfix) with ESMTP id 7AC76E0BB3 for ; Sat, 25 May 2013 19:19:55 +0000 (UTC) Received: from TOMWIJ-GENTOO ([94.226.55.127]) by georges.telenet-ops.be with bizsmtp id gKKu1l0092khLEN06KKuub; Sat, 25 May 2013 21:19:54 +0200 Date: Sat, 25 May 2013 21:17:50 +0200 From: Tom Wijsman To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Usage of dev-utils/ninja in ebuilds Message-ID: <20130525211750.61b81a57@TOMWIJ-GENTOO> In-Reply-To: <51A1077E.1030607@gentoo.org> References: <51A1077E.1030607@gentoo.org> X-Mailer: Claws Mail 3.9.0 (GTK+ 2.24.18; 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: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/ytrhy2i6OQ8VcOo6MAABKVu"; protocol="application/pgp-signature" X-Archives-Salt: 40ccb5d1-7eb2-4d13-b815-18db847ad6e2 X-Archives-Hash: 0125bac71d9aa68a308b654eb1705f2e --Sig_/ytrhy2i6OQ8VcOo6MAABKVu Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Sat, 25 May 2013 14:48:30 -0400 Mike Gilbert wrote: > For those unaware, dev-util/ninja is a make-replacement created by one > of the Chromium guys at Google. Its focus is on making incremental > builds of large software faster. I've no idea how this would work out, so I'm asking some questions from different perspective to form a better idea; this may step aside your discussion but on the other hand could help other unaware developers. If I missed earlier ML discussions on this by not paying attention or being too new, feel free to point me to those; no need to repeat. :) =46rom 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? =46rom a developer perspective, aside from the above feature, are there any other features that make ninja interesting to use in cmake ebuilds? When should it be used? =46rom 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? =46rom 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.) > 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? 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. 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 allow maintainer's to override the user, then splitting them is back in favor. But well, this is based on preliminary thoughts without really properly knowing what the advantages and disadvantages here are. Hopefully you can shed some light here, thanks in advance. --=20 With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : TomWij@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D --Sig_/ytrhy2i6OQ8VcOo6MAABKVu Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (GNU/Linux) iQEcBAEBAgAGBQJRoQ5iAAoJEJWyH81tNOV9WxAH/jAb1i7W3RiypOZw2E447Sx/ /5Fx4/YNwk8eFan/nRAczJXNTjRRlXw6+8Sfds7EhcrvWRxrOLDXW+tjsCopNt74 yekO7XY8BEwmS7KI62iqUQutA7aY2+HQ9XMhId2UECxsKc0W66B0dF4KDHLDNsce N+V/4pIBeGA3tqLNDoudIEVSfEqCY6usuNVdKI06Gd4jO9n+N0M44FkGZA/GMhig CkU6fv9jcPtt/5xp7qAZMrtikOjPfUh6jE0ENXw12envYYs0FSf5O/gE6Hz1oXRH G1Bk/cQCSZ4Tm+gtC8N/BDIWXGNR0A/ihqeagSrnUHDD/kZDlMCX6mOKqHJPyDM= =cgjg -----END PGP SIGNATURE----- --Sig_/ytrhy2i6OQ8VcOo6MAABKVu--