Also there was a post about why just generating ninja using python can be a good option. I do this in my project and it has been very productive so far. I couldn’t find this post now but it was saying to use ninja_syntax.py from ninja codebase and just doing something minimal for a project
bsimpson 1 hours ago [-]
Evan Martin (evmar) started Ninja when he was working on Chrome at Google:
If someone sees this: The ninja package on PyPI [0] currently stays at version 1.13.0 . There is an issue in 1.13.0 preventing it building projects on Windows. The issue is already fixed in 1.13.1 almost a year ago, but the PyPI package hasn't got an update, see [1], and many downstream projects have to stay at 1.11 . I hope it could update soon.
Probably for the same reason other binaries are distributed by npm: lack of cross platform general package managers and registries
mikepurvis 4 hours ago [-]
Also for cases where a python project needs to depend on it.
verdverm 2 hours ago [-]
Or lack of a tool like Goreleaser in the language ecosystem that handles that
j1elo 4 hours ago [-]
What a messy and frankly, absurd situation to be left in. To fork a project in order to provide a tool through Pypi, only to then stop updating it on a broken version. That's more a disservice than a service for the community... If you're going to stay stuck, better to drop the broken release and stay stuck on the previous working one.
mizmar 1 hours ago [-]
Similar to make, it does mtime chronological comparison of dependencies with target to determinate if dependencies changed. This is just so flawed and simple to fool by operations on filesystem that do not change mtime (move, rename):
1) pick a source file and make a copy of it for for later
2) edit selected source file and rebuild
3) move the copy to it's original location
4) try to rebuild, nothing happens
By not tracking file metadata through an index file, mtime-only incremental build systems trade a lot of reliability for only slightly more simplicity. https://apenwarr.ca/log/20181113
loeg 1 hours ago [-]
Copy (1) and edit (2) both bump mtime, usually. It's not obvious that in the workflow you describe ninja is problematic, rather than the workflow itself (which is atypical).
mizmar 19 minutes ago [-]
ninja fails to detect that file changed from last build - all it's mtime, ctime, inode and size can change, yet it's not detected as long as mtime is not newer than target.
jasonpeacock 1 hours ago [-]
My guess is that it's for drop-in compatibility with make.
There is (at least) one open issue about this - the solution/alternatives are not trivial:
Postgres uses Meson+Ninja in their builds. That seems like a pretty big endorsement.
ddtaylor 2 hours ago [-]
Most of Gnome is built using that too.
p4bl0 1 hours ago [-]
I used ninja only a few years ago when contributing to KDE software (Dolphin, Kate, KTextEditor, etc.). I had no prior experience with it and it was easy to apprehend, so a rather good experience.
Svoka 28 minutes ago [-]
Ninja religions following of treating timestamps (mtime) as 'modified' marker makes it useless with Git and large projects.
You switched some branches back and forward? Enjoy your 20 minutes rebuild.
I believe the same author has made a ninja successor (n2) that uses hashes instead. Haven't tried personally but hopefully get around to try that in the near future
menaerus 16 minutes ago [-]
I have never observed that issue, and I have been using it to build MMLoC repositories. Perhaps the reason being is that I always use it coupled with ccache. Have you tried that?
throwway120385 2 minutes ago [-]
ccache is a workaround for the mtime problem. You can either hash with ccache or hash directly in the build system, but either way there's no substitute for hashing something. Ccache is hashing the input to the build, but there may be elements of the build that lie outside of ccache's awareness that having a hash-aware build system would take care of. Partial rebuilds devolve to a cache invalidation problem pretty quickly either way.
shevy-java 8 hours ago [-]
All the main build tools (cmake, meson/ninja and GNU configure) have different benefits. For instance, I expect "--help" to work, but only really GNU configure supports it as-is. I could list more advantages and disadvantages in general here, but by and large I prefer meson/ninja. To me it feels by far the fastest and I also have the fewest issues usually (excluding python breaking its pip stack but that's not the fault of meson as such). ninja can be used via cmake too but most uses I see are from meson.
flohofwoe 7 hours ago [-]
> ninja can be used via cmake too but most uses I see are from meson
How do you know though when the choice of cmake-generator is entirely up to the user? E.g. you can't look at a cmake file and know what generator the user will select to build the project.
FWIW I usually prefer the Ninja generator over the Makefile generator since ninja better 'auto-parallelises' - e.g. with the Makefile generator the two 'simple' options are either to run the build single-threaded or completely grind the machine to a halt because the default setting for 'parallel build' seems to heavily overcommit hardware resources. Ninja just generally does the right thing (run parallel build, but not enough parallelism to make the computer unusable).
plq 5 hours ago [-]
ninja supports separate build groups and different max number of parallel jobs for each. CMake's ninja generator puts compilation and linking steps in their own respective groups. End result is by default `nproc` parallel jobs for compilation but 1 job for linking. This helps because linking can be way more memory intensive or sometimes the linker itself has support for parallelism. Most projects have only a handful of linking steps to run anyway.
Sesse__ 2 hours ago [-]
I find Meson's --help fairly useful, at least compared to the disaster that is CMake's. (Try to find out, as a user not experienced with either, how you'd make a debug build.) I agree that configure --help is more useful for surfacing project-specific options, though.
sluongng 4 hours ago [-]
My teammate has a great time reimplementing Ninja (slop-free) in Go here https://github.com/buildbuddy-io/reninja to make it even faster with Remote Build Execution.
setheron 4 hours ago [-]
This is cool. Going to see if I can use it at work.
mjbstrategic 46 minutes ago [-]
[dead]
jonstewart 5 hours ago [-]
The absolute best thing about coding agents is not having to waste time on build systems. I had Claude code port my autotools scripts to meson (which uses ninja) and it’s been a huge quality of life improvement.
hakrgrl 3 hours ago [-]
Getting builds to work was some of the most tedious, least interesting work. It is so satisfying to watch the agent try 4 different things and magically go on its way. No more makefile syntax searches or cmake hell.
freedomben 23 minutes ago [-]
For real. I stopped writing Makefiles because of how tedious it was, but now with AI I'm back to throwing Makefiles in everything. It's wonderful to have the same build, test, release commands in all projects instead of mix compile in one, npm build in another, etc. This is my favorite part of AI
reactordev 5 hours ago [-]
Soon you won’t even have to waste time on the code part…
tom_ 5 hours ago [-]
It's only a waste of your tine if you don't want to do it.
throwaway613746 3 hours ago [-]
[dead]
chmorgan_ 5 hours ago [-]
[dead]
amelius 3 hours ago [-]
I can remember having to uninstall ninja temporarily because it messed with building packages. I only use it because other packages need it.
Some blog posts from the creator of ninja:
https://neugierig.org/software/blog/2018/07/options.html
https://neugierig.org/software/blog/2011/04/complexity.html
Also there was a post about why just generating ninja using python can be a good option. I do this in my project and it has been very productive so far. I couldn’t find this post now but it was saying to use ninja_syntax.py from ninja codebase and just doing something minimal for a project
https://neugierig.org/software/chromium/notes/2011/02/ninja....
Hence, it's used in a lot of Google projects.
[0] https://pypi.org/project/ninja/
[1] https://github.com/scikit-build/ninja-python-distributions/i...
1) pick a source file and make a copy of it for for later 2) edit selected source file and rebuild 3) move the copy to it's original location 4) try to rebuild, nothing happens
There is (at least) one open issue about this - the solution/alternatives are not trivial:
https://github.com/ninja-build/ninja/issues/1459
You switched some branches back and forward? Enjoy your 20 minutes rebuild.
* https://github.com/ninja-build/ninja/issues/1459
How do you know though when the choice of cmake-generator is entirely up to the user? E.g. you can't look at a cmake file and know what generator the user will select to build the project.
FWIW I usually prefer the Ninja generator over the Makefile generator since ninja better 'auto-parallelises' - e.g. with the Makefile generator the two 'simple' options are either to run the build single-threaded or completely grind the machine to a halt because the default setting for 'parallel build' seems to heavily overcommit hardware resources. Ninja just generally does the right thing (run parallel build, but not enough parallelism to make the computer unusable).