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

Faster Than Ninja

build2.org

Post reply on HN
Print view View original

21–30 of 41 posts

Re: Faster Than Ninja

#21

Post by wpollock »

shevy-java wrote: post #9

Great that there are performance benefits, but one thing that I think both meson/ninja and cmake (or cmake/ninja) got wrong, and GNU configure got right is "./configure --help". Why do neither of these tools simply add --help here? Yes, their syntax is different, but the issue is not only about --help. Often I could disable documentation or man page via --disable-man or --disable-doc or something like that. I recentl…

> He thinks everyone needs manpages. I told him I never look at any local man page ever; I only look online for help...

Everyone's workflow is different. Your's obviously works for you and many others.

But I like local man pages. They get updated at the same time as the software is updated. Sometimes I have an older version of software and the online version is for a newer version, or vice-versa. Local man pages are always available and generally quicker than accessing them online.

If the machines in question are mult user, you should always install local documentation regardless of your personal preferences.

Re: Faster Than Ninja

#22

Post by Orphis »

shevy-java wrote: post #9

Great that there are performance benefits, but one thing that I think both meson/ninja and cmake (or cmake/ninja) got wrong, and GNU configure got right is "./configure --help". Why do neither of these tools simply add --help here? Yes, their syntax is different, but the issue is not only about --help. Often I could disable documentation or man page via --disable-man or --disable-doc or something like that. I recentl…

This is not purely a CMake problem, this is a maintainer problem. It's absolutely possible to not define the man page targets if the related tools are not found, or to add a variable to disable that.

In practice, it does show the limitations of the CMake model though. You should not be paying the price to generate the build files for bits you don't care about. You should be able to just load the CMake files and build a target, ignoring the rest.

This is how tools like Bazel function and that allows them to scale to very large monorepos. Build files are only processed when a target from that folder is built directly or used. CMake has to load everything as it does not know about the build tree and the maintainer has to manage exclusion lists or inclusion lists.

Re: Faster Than Ninja

#23

Post by evmar »

bellowsgulch wrote: post #19
evmar wrote: post #4

[Ninja author here] Nice post, cool to see the deep dive! I also appreciate the details on how they produced their numbers. As they observe, Ninja gets to be fast mostly by cheating: it avoids a lot of work by saying many things are just out of scope for Ninja to do, and that means it is a useful a target to race against. (Funny thing: when I wrote Ninja I was misremembering how fast an earlier build system was so I…

Thank you for your work on Ninja. It's just really good.

Thanks for saying this! I am close enough to it that I mostly remember all of the bad decisions I made that are now unfixable, haha.

Re: Faster Than Ninja

#24

Post by bellowsgulch »

evmar wrote: post #23
bellowsgulch wrote: post #19

Earlier quoted context omitted.

Thank you for your work on Ninja. It's just really good.

Thanks for saying this! I am close enough to it that I mostly remember all of the bad decisions I made that are now unfixable, haha.

Better to have made imperfectly and learned than to not have made at all. :)

Re: Faster Than Ninja

#25

Post by bluGill »

sramsay wrote: post #17
shevy-java wrote: post #9

Great that there are performance benefits, but one thing that I think both meson/ninja and cmake (or cmake/ninja) got wrong, and GNU configure got right is "./configure --help". Why do neither of these tools simply add --help here? Yes, their syntax is different, but the issue is not only about --help. Often I could disable documentation or man page via --disable-man or --disable-doc or something like that. I recentl…

I think what you're talking about is part of a much larger pattern. Autotools imagines that the most important thing is the "user" in a world where people want to download your software and build it on their machine. They don't care (as much) about fast build times, the semantic clarity of the build files themselves, the ease with which one may change or extend the build sequence, test harnesses . . . Those are all d…

> They do care that the code can compile on their (possibly old) machine.

In my experience is it doesn't work. Sure it can be made to work and autotools asks all the right questions. However in the real world I have yet to see an autotools project that works out of the box in my custom environment.

Meanwhile cmake just worked every time when I plugged in the toolchain file that I created for the very first project I needed to build for my environment.

Again, it isn't that autotools cannot do what is claims. However nobody gets the details right and so something doesn't work. That something is different for every project. In the end what works is either what someone takes the time to make work and those things that are "very close". My project is cross compiling linux, which cmake does well (autotools also messed something up, often failing to use the sysroot paramater where needed)

Re: Faster Than Ninja

#26

Post by Alecazam »

evmar wrote: post #4

[Ninja author here] Nice post, cool to see the deep dive! I also appreciate the details on how they produced their numbers. As they observe, Ninja gets to be fast mostly by cheating: it avoids a lot of work by saying many things are just out of scope for Ninja to do, and that means it is a useful a target to race against. (Funny thing: when I wrote Ninja I was misremembering how fast an earlier build system was so I…

I feel like make/ninja suffer from the same output modstamp > input modstamps to rebuild. Really a build system should track modstmaps on all inputs (apps included), and the rebuild on not-equal.

Would be nice to see build2 go this route.

Re: Faster Than Ninja

#27

Post by zX41ZdbW »

evmar wrote: post #4

[Ninja author here] Nice post, cool to see the deep dive! I also appreciate the details on how they produced their numbers. As they observe, Ninja gets to be fast mostly by cheating: it avoids a lot of work by saying many things are just out of scope for Ninja to do, and that means it is a useful a target to race against. (Funny thing: when I wrote Ninja I was misremembering how fast an earlier build system was so I…

Thank you for Ninja!

The speed (reading the build.ninja file) was never a concern for us. If I could share a wish-list, it will be:

- Fix the possibility of a segmentation fault when the build file is damaged;

- Use a better order of execution: https://github.com/ninja-build/ninja/issues/2157

Re: Faster Than Ninja

#28

Post by evmar »

Alecazam wrote: post #26
evmar wrote: post #4

[Ninja author here] Nice post, cool to see the deep dive! I also appreciate the details on how they produced their numbers. As they observe, Ninja gets to be fast mostly by cheating: it avoids a lot of work by saying many things are just out of scope for Ninja to do, and that means it is a useful a target to race against. (Funny thing: when I wrote Ninja I was misremembering how fast an earlier build system was so I…

I feel like make/ninja suffer from the same output modstamp > input modstamps to rebuild. Really a build system should track modstmaps on all inputs (apps included), and the rebuild on not-equal. Would be nice to see build2 go this route.

I did some exploration of this idea in a followup build system! See https://neugierig.org/software/blog/2022/03/n2.html . (It's not really production-ready.)

Re: Faster Than Ninja

#29

Post by vient »

bluGill wrote: post #14

Cmake spend 15 seconds to generate this project? I find it unlikely build2 is doing the same work as cmake is. Now I will grant cmake is single threaded and slow, so there is a lot of room to do the things it does better (the language sucks, and is part of what forces single threaded). It also wouldn't surprise me if cmake is doing things that are not really needed (odds are the default compiler works - most of the t…

Not only is CMake single threaded but the generation step time scales almost quadratically* with the number of targets in some cases. Probably not what happens here but this is what forced us to move from CMake — generation times were surpassing 5 minutes, and this is not counting configuring step.

* Because in CMake there are several target properties that may be affected by the "parent" (another target which added this target as dependency), meaning that these properties need to be re-evaluated in the context of each root target dependent on this one. If I remember correctly, exact mechanism is that some properties can have generator expressions, and these expressions can reference "parent" target. Now we imagine an app which has some std lib with 1k targets, and 100 top-level executables dependent on this std lib - suddenly we have 100k target evaluations in generation step.

Re: Faster Than Ninja

#30

Post by feelamee »

evmar wrote: post #23
bellowsgulch wrote: post #19

Earlier quoted context omitted.

Thank you for your work on Ninja. It's just really good.

Thanks for saying this! I am close enough to it that I mostly remember all of the bad decisions I made that are now unfixable, haha.

I would like to read blogpost about this and what could be done better.
Post reply on HN