Re: [dev] [ANN] samurai: ninja-compatible build tool

From: Michael Forney <mforney_AT_mforney.org>
Date: Wed, 26 Jul 2017 09:32:15 -0700

On 7/26/17, Anselm R Garbe <garbeam_AT_gmail.com> wrote:
> On 26 July 2017 at 09:05, Silvan Jegen <s.jegen_AT_gmail.com> wrote:
>> That's what I suspected. Not sure it's desirable to ever work on a
>> codebase big enough to require a build system which uses ninja under
>> the hood. If I find myself in such a position I will turn to samurai
>> first.
>
> Out of curiosity, what is the point of a build system like ninja, if
> the codebase requires to be complex?

ninja doesn't require the codebase to be complex, but does tolerate
it. Anyway, I'm a little suprised about the distaste for ninja since
it's features are pretty much the same as POSIX make (variable
assignments and rule definitions). The main differences being

- In make, variable assignments are evaluated only when used. In
ninja, they are evaluated at the assignment.
- In make, inference rules are used to run the same command template
for many different targets. In ninja, rules specify the
command-template and build lines invoke the rule.
- In make, a new scope (to change CFLAGS/LDFLAGS for instance) can
effectively be introduced with a recursive call to make. In ninja, you
can include another ninja file with a new scope using `subninja`.
- make is standardized and ninja is not.

In oasis I'm using ninja like you're use stali.mk in stali. The
advantage is that dependencies are tracked throughout all packages
(not only within a package and between packages), so I can edit a file
in some library (libcurl for instance), and git, mupdf, and netsurf
all get rebuilt automatically. The disadvantage of course is it's not
a standard UNIX tool.

> Isn't the issue to be tackled the
> codebase complexity then?

Yes ideally projects like llvm and chromium would instead focus on
codebase complexity. But the argument that ninja is bad because bad
projects use it does not make sense to me.
Received on Wed Jul 26 2017 - 18:32:15 CEST