Received: from mx1.tetrasec.net (mx1.tetrasec.net [74.117.189.118]) by nld3-dev1.alpinelinux.org (Postfix) with ESMTPS id 72725782B7E for <~alpine/devel@lists.alpinelinux.org>; Wed, 11 Dec 2019 08:41:24 +0000 (UTC) Received: from mx1.tetrasec.net (mail.local [127.0.0.1]) by mx1.tetrasec.net (Postfix) with ESMTP id 578EB2DE3845; Wed, 11 Dec 2019 08:41:23 +0000 (UTC) Received: from ncopa-desktop.copa.dup.pw (67.63.200.37.customer.cdi.no [37.200.63.67]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: alpine@tanael.org) by mx1.tetrasec.net (Postfix) with ESMTPSA id AC7B12DE1644; Wed, 11 Dec 2019 08:41:22 +0000 (UTC) Date: Wed, 11 Dec 2019 09:41:16 +0100 From: Natanael Copa To: "Drew DeVault" Cc: <~alpine/devel@lists.alpinelinux.org> Subject: Re: Proposal: replace ninja with samurai Message-ID: <20191211094116.4908c616@ncopa-desktop.copa.dup.pw> In-Reply-To: References: X-Mailer: Claws Mail 3.17.4 (GTK+ 2.24.32; x86_64-alpine-linux-musl) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Sat, 07 Dec 2019 12:37:56 -0500 "Drew DeVault" wrote: > Ninja is a build tool which fills the same niche as Make, and samurai is > a third-party implementation on of Ninja. > > https://github.com/ninja-build/ninja > https://github.com/michaelforney/samurai > > samu is much simpler than ninja, clocking in at around ~3,000 lines of > C, compared to Ninja's ~20,000 lines of C++. samu also supports a > SAMUFLAGS environment variable which we can use to tune the -j flag in > abuild, similar to Make. Samurai is a drop-in replacement, but is not > bug-for-bug compatible with Ninja. What I think is nice with ninja compared to make, is that we don't need set -j to make it use all cores. Will samurai not use all detected cores without setting -j? > Ninja upstream has been hostile to appeals from distros and users > alike to add a similar environment variable. Their argument seems to > boil down to being proud to only support one environment variable, > which can change the format string their progress meter is printed > with. Their attitude is non-cooperative towards distros, and I would > rather use an implementation which plays more nicely with others. Do you have any example with hostility or non-cooperative against Alpine? I am against this change if it is purely for political reasons. > I've been using samu as my daily driver for a few years now, and I've > yet to meet a project it couldn't compile. Its performance is also > comparable to ninja. A samurai package is available in community on edge > if you would like to try it for yourself. Does chromium build with samurai? Does chromium developers support builds with samurai? > I propose dropping the ninja package and adding provides=replaces=ninja > to the samurai package, as well as a symlink from /usr/bin/ninja to > /usr/bin/samu. I'd like to have them both available so we can easily pick one depending on which works or is supported. I also saw that there was a comparison with pkg-config vs pkgconf on IRC. The main motivator for pkgconf switch was that pkg-config introduced a circular dependency (pkg-config -> glib -> pkg-config). The pkgconf author is also an Alpine developer so any issues we had with pkgconf were fixed very quick upstream. Do we have similar problems with ninja? Can we expect the same level of support from samurai that we have with pkgconf? -nc