3 ms·
Honestly, I never quite understood the point of generating the makefiles: if you have a tool that knows where the inputs are, where the outputs should be, and t
by Joker_vD 4y ago
Honestly, I never quite understood the point of generating the makefiles: if you have a tool that knows where the inputs are, where the outputs should be, and tracks the dependencies changing from build to build (something that "make" famously struggles to do), then surely that tool can also run whatever compilers/linkers/etc. are needed?
I guess you can commit the generated makefile into your repo so that those who want to build your project from sources don't need your custom build tool installed, only make...
- tuyiown 4y agoHistorically, Makefiles generation is merely a cache of platform introspection on systems that were orders of magnitudes slower than what we have now. I suspect that any other approach based on Makefile only would have implied higher memory consumption and/or implied slow rotating disk I/O.
- account42 4y agoActually on my 64-thread Threadripper that cache is more important than ever as the make step parallelizes nicely but the configure step usually is 100% serialized.
- rossmohax 4y agoThere are many nuances. How to control parallelism, how to present output, checking freshness, etc. It is much easier to generate Ninja files and let Ninja do all the boring work.
- zelphirkalt 4y agoWhat are the dependencies of Ninja? (I seem to remember it being a Python tool?)
- flohofwoe 4y agoOn macOS at least, Ninja is just a 362 kByte native executable without dependencies except dynamically linking with the system-provided libc++ and libSystem DLLs (you're probably thinking of Meson?)
- zelphirkalt 4y agoAh, that might be it! Thanks!
- trasz 4y agoTake a look at FreeBSD. Here’s what a typical Makefile looks like: # $FreeBSD$ PACKAGE=runtime PROG= setfacl SRCS= file.c mask.c merge.c remove.c setfacl.c util.c .include <bsd.prog.mk> So, yeah, at least for code in C you can have something maintainable in make(1), it’s just you need to structure your project in a sensible way.
- stkdump 4y agoDoes it support incremental builds? How does it detect include dependencies? Is it portable?
- trasz 4y ago1. Sure (if you didn’t need incremental builds, why bother with make at all? Just use sh.) 2. It doesn’t, it’s programmers job to make an effort to append a file name to a single line in a single file. 3. It’s portable in the same way autotools are portable, which means you can make it work with relative ease.
- PaulDavisThe1st 4y agoDo you want to hand parallelization in your little custom tool?
- Joker_vD 4y agoWell, cargo has it. So does go build. And dune. And MSBuild. And... basically, every language-specific (and non-specific) build tool out there handles it, so yes? Sure, it's not exactly according to the UNIX philosophy but judging by other comments in this thread, if one wants a low-level parallelizeable build tool, they should use Ninja instead of Make anyhow.
- colonwqbang 4y agoMost builds are divided into two phases. The first phase "do we have libfoo installed, where is doxygen, are tests enabled" is run infrequently. The second phase "recompile everything that needs to be recompiled" is run over and over again. The second phase is more or less a solved problem now given that Ninja exists. The first phase is where a lot of people have different ideas and tastes, so we get cmake, meson, autotools, etc. You can certainly do everything in one system. In practice this seems to lead to a build process that is much slower than it needs to be, see for instance Scons.
- Joker_vD 4y agoOr see cargo, go build, dune, etc.
- colonwqbang 4y agoThese are all tools that specialise in building only a particular kind of project. They are useful, but aren't really in the same category of general build tools like Ninja and Make.