5 ms·

Am I the only one who thinks make is fine for 80% of the things that these new build systems popping out every day are trying to solve?

by rtz12 11y ago

Peaker 11y ago
The problem with `make` (and all build systems that generate `Makefiles` for `make`) is both flexibility and correctness. Correctness problems: * Make cannot correctly specify file system state dependencies (like inexistence of files, such as include files in include paths prior to the found location). * Make doesn't protect against accidental edits of source code while it is being built, poisoning the result files. When you try to run "make" again, it will say nothing is to be done, but the result file [with its newer mtime] can actually be based the pre-save source file. * Make uses < and > for mtime checks (not just ==) and that is incorrect on some operating systems (e.g: Windows). * Make offers no practical way to track or enforce system-level dependency changes. * Easily miss stderr printouts from compilers/etc, if you missed them at the first time around (losing mainly gcc/clang warnings) The "solution" is almost always to "make clean" whenever voodoo bugs are encountered, anything system-level is changed, etc. This is terrible if you expect correctness from your tools. Flexibility-wise, make is also awful, due to one huge problem: Make requires the dependency graph to be fully specified, including all transitive dependencies. This makes code generation a near impossibility -- since you often need to scan the generated code to figure out its dependencies. IOW: Make is a "two-phase" build system, where we really want an "N-phase" build system that interleaves building with dependency scanning/discovery. Also, this is taken for granted, but it is major: Make requires error-prone specification of all file dependencies. This is impractical to do correctly in large, complex projects. Every script being run may have tons of transitive dependencies that are very hard to specify. Any mistake will usually go unnoticed, until you hit a "voodoo bug" and just "make clean". Additionally, make doesn't support any form of advanced caching of previous build results. --- All these problems, and more, made me decide to create my own build system for our complex C project: buildsome[1]. It uses file system hooking to provide both correctness (no more missed input dependencies!) and simplicity (no need to specify each and every transitive dependency, they can be automatically discovered). It checks input files for changes after the build commands (to avoid output file poisoning). It remembers stderr and re-prints it. It supports N-phase builds. And more. [1] https://github.com/ElastiLotem/buildsome https://github.com/ElastiLotem/buildsome
pekk 11y ago
By the time you are reaching for recursive make, if you can't just get rid of the complexity with a rethink, it's probably better to use something different.
earlz 11y ago
No... I think inventing build systems is about as useful as inventing standards at least 80% of the time
felipellrocha 11y ago
Make is fine for small projects. But as soon as your have something more complex in your hands, automating all of that stuff can be a huge productivity saver...
Tomte 11y ago
make has lots and lots of strange little idiosyncracies and things that I would even call bugs. Take, for example, a line from my current makefile: LEFTPAREN:=( It took me lots of studying the manual, googling and stackoverflowing to arrive at that "solution". Because there is no way to quote a left paren. There simply isn't. And I'm grateful at least this stupid workaround is possible.

Am I the only one who thinks make is fine for 80% of the things that these new build systems popping out every day are trying to solve?

by rtz12 11y ago

Am I the only one who thinks make is fine for 80% of the things that these new build systems popping out every day are trying to solve?

Peaker 11y ago

The problem with `make` (and all build systems that generate `Makefiles` for `make`) is both flexibility and correctness. Correctness problems: * Make cannot correctly specify file system state dependencies (like inexistence of files, such as include files in include paths prior to the found location). * Make doesn't protect against accidental edits of source code while it is being built, poisoning the result files. When you try to run "make" again, it will say nothing is to be done, but the result file [with its newer mtime] can actually be based the pre-save source file. * Make uses < and > for mtime checks (not just ==) and that is incorrect on some operating systems (e.g: Windows). * Make offers no practical way to track or enforce system-level dependency changes. * Easily miss stderr printouts from compilers/etc, if you missed them at the first time around (losing mainly gcc/clang warnings) The "solution" is almost always to "make clean" whenever voodoo bugs are encountered, anything system-level is changed, etc. This is terrible if you expect correctness from your tools. Flexibility-wise, make is also awful, due to one huge problem: Make requires the dependency graph to be fully specified, including all transitive dependencies. This makes code generation a near impossibility -- since you often need to scan the generated code to figure out its dependencies. IOW: Make is a "two-phase" build system, where we really want an "N-phase" build system that interleaves building with dependency scanning/discovery. Also, this is taken for granted, but it is major: Make requires error-prone specification of all file dependencies. This is impractical to do correctly in large, complex projects. Every script being run may have tons of transitive dependencies that are very hard to specify. Any mistake will usually go unnoticed, until you hit a "voodoo bug" and just "make clean". Additionally, make doesn't support any form of advanced caching of previous build results. --- All these problems, and more, made me decide to create my own build system for our complex C project: buildsome[1]. It uses file system hooking to provide both correctness (no more missed input dependencies!) and simplicity (no need to specify each and every transitive dependency, they can be automatically discovered). It checks input files for changes after the build commands (to avoid output file poisoning). It remembers stderr and re-prints it. It supports N-phase builds. And more. [1] https://github.com/ElastiLotem/buildsome https://github.com/ElastiLotem/buildsome

pekk 11y ago

By the time you are reaching for recursive make, if you can't just get rid of the complexity with a rethink, it's probably better to use something different.

earlz 11y ago

No... I think inventing build systems is about as useful as inventing standards at least 80% of the time

felipellrocha 11y ago

Make is fine for small projects. But as soon as your have something more complex in your hands, automating all of that stuff can be a huge productivity saver...

Tomte 11y ago

make has lots and lots of strange little idiosyncracies and things that I would even call bugs. Take, for example, a line from my current makefile: LEFTPAREN:=( It took me lots of studying the manual, googling and stackoverflowing to arrive at that "solution". Because there is no way to quote a left paren. There simply isn't. And I'm grateful at least this stupid workaround is possible.