Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ninja: A simple way to do builds

jvns.ca

Post reply on HN
Print view View original

51–60 of 92 posts

Re: Ninja: A simple way to do builds

#51

Post by barumi »

patrec wrote: post #17
chrismorgan wrote: post #13

For comparison, here’s a makefile for the trivial example (though you’ll have to fix the indentation): all: $(patsubst ${things_to_convert},%.svg,%.pdf) %.pdf: %.svg inkscape $ ${things_to_convert} is left undefined, as in the source article. It might be something like $(wildcard [STAR].svg) or $(shell find src -name '[STAR].svg'). [Turn each [STAR] into *; HN formatting idiosyncrasies are in play.] I like makefiles…

You are not wrong, but if the world where not full with even worse build systems it'd be a bit saying I prefer to drink from puddles because I find them wherever I go. Make is everywhere, but apart from UX issues such as the dumb syntax or the different flavors you'll encounter, the fundamental problem with it is that it just can't build things properly (the existence of make clean is the dead give away here). That's…

> You are not wrong, but if the world where not full with even worse build systems it'd be a bit saying I prefer to drink from puddles because I find them wherever I go.

That assertion is quite wrong. If you really want to go with that metaphor them the alternative to drinking from all the puddles you have readily available is to ignore them all and instead resort to waste time digging your own hole in the ground each and every single time you feel a little thirsty.

Then, in the only practical and conceivable advantage you get from all the extra work is to allow you to enjoy a particular earthy flavour that in the end can't be objectively described as an improvement.

Re: Ninja: A simple way to do builds

#52

Post by sbierwagen »

busrf wrote: post #8
AtlasBarfed wrote: post #7

Earlier quoted context omitted.

... What mechanism is used to perform incremental builds? It is referenced in the article and unexplained from what I can tell. What enables "quickly" for you to determine what needs to be built? Make simply compares timestamps I believe. ... What mechanisms/tricks speed up builds? Or is it just the "simplicity" that is the BFD? Edit: It sure would have been helpful if somewhere was stated: "the build system of Chrom…

Ninja uses time stamps. See the “Comparison to Make” section in the linked manual.

Isn't using mtime a bad idea? https://news.ycombinator.com/item?id=18473744

Re: Ninja: A simple way to do builds

#53

Post by liuliu »

gravypod wrote: post #38
dcolkitt wrote: post #37

Earlier quoted context omitted.

Out of curiosity, how difficult did you find the migration process? Especially in terms of having to restructure the project. I have no direct experience, but from what I've heard Bazel is very opinionated about structure. Which makes it particularly challenging to migrate pre-existing projects that may not conform to its view. But again this all hearsay, so I'd like to hear from someone with direct experience.

It was pretty easy for the software I was migrating because it was already in a monorepo and we were already using some very similar conventions. Anyone writing Java code that uses Gradle or Maven shouldn't have much pain migrating. I'm acutally currently supporting both Gradle and Bazel on the same backend code base to give another team (who depends on my code) a chance to gracefully migrate. The "hardest" thing to…

For cc_library, I think now you can add include paths so `#include "somethingUnderYourPath"` will be easier.

Re: Ninja: A simple way to do builds

#54

Post by kingosticks »

barumi wrote: post #48
bachmeier wrote: post #27

Earlier quoted context omitted.

> I like makefiles in substantial part because there’s a very high probability of Make already being installed. I’m comfortable enough with them that I didn’t need to look anything up to write any of what I wrote above. There's an even higher probability of Perl being installed, and I'd much rather use that than Make. I've even been known to write a Perl script that calls Make after doing something complex that would…

> There's an even higher probability of Perl being installed You're showing your ignorance there, champ. Make is one of the utilities that's required by the UNIX specification,which means that each and every single UNIX or UNIX-like OS is required to make Make available to users in order to be considered an UNIX. So to make this quite explicit, for starters each and every install of macOS ships with make.

They said 'installed', not 'available'.

Re: Ninja: A simple way to do builds

#55

Post by barumi »

kingosticks wrote: post #54
barumi wrote: post #48

Earlier quoted context omitted.

> There's an even higher probability of Perl being installed You're showing your ignorance there, champ. Make is one of the utilities that's required by the UNIX specification,which means that each and every single UNIX or UNIX-like OS is required to make Make available to users in order to be considered an UNIX. So to make this quite explicit, for starters each and every install of macOS ships with make.

They said 'installed', not 'available'.

In your personal opinion why do you believe that installed software is not available?

Because make is indeed installed on all UNIX, otherwise they are not UNIX.

Re: Ninja: A simple way to do builds

#56

Post by pantsbuild »

gravypod wrote: post #33

I wish more people were taking a look at Bazel, and the Bazel-family, of build systems. I've looked at Meson/Ninja/Make and it works but it's truely very complicated and very difficult to get hermetic & reproducible builds from these systems. In my opinion, Bazel will be the future once the currently ongoing external dependency management design doc is implemented. I've migrated quite a few builds to bazel at work an…

In the general category of Bazel-alike build systems, I'd humbly submit that Pants v2 is worth taking a look at. It's a generic, high performance build system for large projects, implemented in Rust with a Python plugin API. The project had a large announcement today in fact! https://news.ycombinator.com/item?id=24911148

For supported languages (the 2.0.0 release and API is brand new, so only Python and Bash are supported so far), the amount of per-file boilerplate is nearly as low as it goes: https://www.pantsbuild.org/docs/how-does-pants-work#dependen...

Re: Ninja: A simple way to do builds

#57

Post by barumi »

dan00 wrote: post #19
patrec wrote: post #17

Earlier quoted context omitted.

You are not wrong, but if the world where not full with even worse build systems it'd be a bit saying I prefer to drink from puddles because I find them wherever I go. Make is everywhere, but apart from UX issues such as the dumb syntax or the different flavors you'll encounter, the fundamental problem with it is that it just can't build things properly (the existence of make clean is the dead give away here). That's…

> - if your paths have white space in them, you are generally fucked Paths containing ':' are also fun. That make doesn't handle paths - and most likely other things - as a unit, but just substitutes their string representation into the makefile, is just asking for trouble.

> Paths containing ':' are also fun.

To be fair, anyone who uses reserved/special characters in file names is asking for trouble in pretty much any usage.

Re: Ninja: A simple way to do builds

#58

Post by emmelaich »

cassepipe wrote: post #43
codemac wrote: post #34

Earlier quoted context omitted.

> > - if your paths have white space in them > > This is probably my second biggest complaint about Make. If only more of the world used rc instead of bash, we'd be in a better place.

rc?

https://en.wikipedia.org/wiki/Rc

An alternate shell, from Plan9.

Re: Ninja: A simple way to do builds

#59

Post by barumi »

gravypod wrote: post #47
Ericson2314 wrote: post #42

Earlier quoted context omitted.

Bazel is a decent idea but poor execution. I think Nix is the future because it already has the "external dependency" part on lock and it's just a matter of making more fine-grained stuff. Meson + Nix skipping the Ninja part I would really like to see. I prefer it when the "big dumb builder" and DSLs are developed a bit separately, too. Agreed Ninja's lack of purity is a real bummer.

I'm not so sure about Nix since it seems much more complex in presentation. The meat and potatoes of Bazel is the BUILD langauge. There may be some warts right now but the community is attempting to address these warts. Difficulty around specifying versions of packages, semantics for building containers, etc. Nix users do not seem to think it's build language is complex. I think Nix might be the worlds best attempt a…

> There may be some warts right now but the community is attempting to address these warts.

Some of Bazel's design problems do feel like the outcome of a poorly executed requirements gathering process. Last time I checked, it assumed for some reason that C/C++ interface headers shared a common root folder with libraries, and if that root folder is not the immediate parent folder then it ends up including all files within that tree branch in its scope.

I also recall that the process of including system libraries that don't support Bazel is needlessly convoluted, and involved adding libraries and interface headers in separate targets just to be able to control visibility. This design oversight was specially disheartening because it made it quite clear that the use case of supporting external packages benefitted from zero attention.

Re: Ninja: A simple way to do builds

#60

Post by barumi »

slezyr wrote: post #39
gravypod wrote: post #33

I wish more people were taking a look at Bazel, and the Bazel-family, of build systems. I've looked at Meson/Ninja/Make and it works but it's truely very complicated and very difficult to get hermetic & reproducible builds from these systems. In my opinion, Bazel will be the future once the currently ongoing external dependency management design doc is implemented. I've migrated quite a few builds to bazel at work an…

For same no one looks at the GYP, GN, and now Bazel. Google bury their build tools just as fast as other products. And something about Java dependency.

To be fair, gyp is quite awful. I mean, a low-level language to generate project files for a few IDEs from a definition file where IDE-specific settings had to be added anyway? While the source of truth is left out of the equation, rendering those project files read-only and forcing developers to reconfigure their IDEs each and every single time they updated the project? This concept seems to have been thought out by masochists.
Post reply on HN