Isn't the ninja build system just a faster replacement for make. I use CMake primarily it lets me create makefiles, ninja files or vs projects. I noticed that in the general case ninja is 5% to 10% faster than make on builds that are more than few seconds long.
Then I found that if I did serious file manipulation at build time, like copy trees of files dependent on other thing in the build, I could have tens of thousands of targets, one per file usually. Ninja might hiccup for a fraction of a second on these shenanigans but make often sits and spins for 20 or minutes.
Unless you want to write the makefile yourself why not use ninja?
Because then I have to ask users to install ninja before they can build my program. In the projects I'm working on, I don't have any of the issues that ninja solves.
You can generate both. That gives you ninja for development (which had a problem you described) while the official builds still can use the makefiles that should result in the same output.
That means that a user who wants to patch the build rules has to have the generator, and learn the generating language instead of the Make language he or she already knows.
Autoconf has this disease. You can build from an official tarball, but touch anything (or use a git checkout) and you need auto-this to generate auto-that. Not just any auto-this, but a specific version, that is seven releases behind current, or else three releases ahead of what your distro provides.
> should result in the same output
It should; but someone has to ensure that it does. That's just another unnecessary concern that doesn't actually have to do with anything with the functionality of whatever is being built. We would like to spend our QA cycles validating the program, not three ways of building it.
Best to have just one way to build, and don't require users to install extraneous tools.
You've confused autoconf with automake. The output from autoconf is just a list of variables that are sourced by your handwritten Makefile, which you can supply yourself if you don't feel like executing autoconf.
It's automake that writes your Makefile for you, but you can just skip using that. E.g. the Git project uses autoconf optionally but not automake.
I know the difference between autoconf and its generated ./configure target.
Your comment overall indicated to me that you were talking about automake, not autoconf. But if not, fair enough.
E.g. you talk about "learn the generating language instead of the Make language". I know you were using that as an example, but there's no general non-horrible replacement for autoconf that you can write by hand, as opposed to automake where you can write a portable Makefile
You can of course write a bunch of ad-hoc shellscripts & C test programs to probe your system, but this is going to be a lot nastier and buggier than just using autoconf to achieve the same goal.
You also don't generally need autoconf to build projects you clone from source control in the same way that you need automake (because that actually makes the Makefile).
The output of autoconf is generally just a file full of variables the Makefile includes, if you don't have that file you can just manually specify anything that differs from the Makefile defaults, e.g. NO_IPV6=YesPlease or whatever.
The Git project, whose autoconf recipe I've contributed to, is a good example of this. You can "git clone" it and just issue "make" and it works, but if the default config doesn't work then "make configure && make" generally solves it, but you can also just e.g. do "make NO_IPV6=YesPlease" if it was lack of IPv6 that was causing the compilation failure. It'll then get your NO_IPV6 variable from the command-line instead of from the ./configure generated config.mak.autogen.
I interpret this as saying that autoconf takes configure.ac as input, and produces a runnable 'configure' script as output. But you are saying that "the output of autoconf is generally just file full of variables the Makefile includes". How can these both be true?
I was using "autoconf" to mean both the software itself and all its output, including the generated configure script.
Confusingly, sorry about that, but for the purposes of discussing what software you need to generate the configure valuables you ultimately need when cloning from source control, it makes no difference.
At first I thought I would have a hard time searching for it with such a simple name, but it clearly is a Haskell tool.
This looks like a reasonable alternative for people who control the whole lifetime of their code, life server software developers. But for someone shipping a library or anything they expect someone else to build, what advantages does this have over Make in the *nix world or CMake in general?
Then I found that if I did serious file manipulation at build time, like copy trees of files dependent on other thing in the build, I could have tens of thousands of targets, one per file usually. Ninja might hiccup for a fraction of a second on these shenanigans but make often sits and spins for 20 or minutes.
Unless you want to write the makefile yourself why not use ninja?