The article keeps on saying that make is "complicated" ... make is an abomination in many, many ways, but claiming that Makefile language is complicated is just sheer ignorance.
Ninja: A simple way to do builds
61–70 of 92 posts
Re: Ninja: A simple way to do builds
#62The article keeps on saying that make is "complicated" ... make is an abomination in many, many ways, but claiming that Makefile language is complicated is just sheer ignorance.
“esoteric”?
Re: Ninja: A simple way to do builds
#63I 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…
Zim was inspired by all of these and has drastically cut build times for our team. We use it to build hundreds of Go, Python, and Node artifacts for use in AWS. https://github.com/fugue/zim
Re: Ninja: A simple way to do builds
#64I 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…
Do you know whether/how it can deal with database tables dependent on source .csv files? My job involves lots of ETL-type work, where the extracted source file(s) for a particular table might have names that include the extract date or version, and a table might depend on other tables. I've been looking at make for dealing with the process, but automatic dependency management seems hard, and dealing with the variable…
Bazel likely won’t deal with this at all, but you could write your own rules to implement something like “insert to a database”.
Re: Ninja: A simple way to do builds
#65Earlier quoted context omitted.
The advantage are the incremental builds they mention. If just one input file changes and you run ninja again, it'll only re-run one step instead of converting all files again.
I'm pretty sure make does that too. The problem is that most people don't know how to write a proper Makefile, even for a simple project, so make ends up doing more work than it should. For small projects, I've tried ninja a while ago, and frankly the effort seemed unjustified, since (a) I already could do the same things with make, and (b) make is already available on most unix-likes. Ninja seems to be better suited…
Yes, Ninja files are very easy to generate, that’s it’s big selling point for me.
I have a project with dozens of C/C++/asm/precompiled libraries, a few thousand source files in all.
I would have trouble writing Makefile(s) for everything that would even be correct, let alone performant, either by hand or generated. But I have a set of Python scripts to generate a big Ninja build file and it all works very nicely.
Re: Ninja: A simple way to do builds
#66Earlier 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…
I think you are missing something about both tools: the BUILD language is still quite high level, and closer to CMake/Meson than Ninja. The Nix language is also the higher level, though not that high level.
The actual "meat and potatoes" of Nix is the derivation graph. I think/hope Bazel has an equivalent, but I'm not sure how exposed it is (advertise your layering, people!). This derivation graph is simple simple as hell---each derivation is a path to an exe, arvgv, environ, etc., and derivations output paths and can depend on the outputs of derivation. This is what Meson/CMake/etc. should learn to output.
Re: Ninja: A simple way to do builds
#67Earlier quoted context omitted.
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 wi…
Monorepos do have advantages, but Google fundamentally uses them as an excuse to fail ot understand modularity and composition. That's a fatal mistake.
Re: Ninja: A simple way to do builds
#68Earlier quoted context omitted.
> - 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.
But linux filename basically allows any byte sequence except EOF and /, so I think it is "make" fault to not being able to support it. Other proper build tools support it correctly.
Re: Ninja: A simple way to do builds
#69I 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…
do you have a link to the design doc?
EDIT: for those searching, I suspect its https://docs.google.com/document/d/1moQfNcEIttsk6vYanNKIy3Zu...
Re: Ninja: A simple way to do builds
#70It is a mistake to imagine Ninja just replacing Make.
Ninja is the "rebuild-it" part of Make, made really, really fast and clean, a joy to use. The Ninja config file is not something you write or, even, look at. It's an intermediate file generated by your build-dependency tool such as CMake, Meson, or even (gods forbid) SCons.
Those are smarter than Make in various ways, but are really not very good at all at actually running builds, so you get them to just make a ninja file, instead, and then get the hell out of your way.
This is good because you don't want to analyze the dependency tree on every build when you haven't changed any of it. So, you just run ninja in your edit-build-test loop.
Ninja is smart enough to rerun Meson or whatever if you do change the build configuration. It understands build directories separate from sources, and ccache compiler wrappers to cache build targets, things you don't want your build-configuation infrastructure to bother with.
Besides being fantastic to use, ninja is worthy of study as a truly superb example of a program that does one thing really, really well, and integrates cleanly with other programs that do other stuff: build analyzers on one side, compilers on the other. It demonstrates a design discipline that we would all be better off if everyone were to follow it.