On 7/26/17, Anselm R Garbe <garb...@gmail.com> wrote: > On 26 July 2017 at 09:05, Silvan Jegen <s.je...@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.