I would much rather just not use make at all than a slightly improved version. A polished turd is still a turd. But if this is a drop in replacement, then this could definitely be very useful.
Calling make a "turd" is understandable, that is, to someone (like myself) who is used to Windows and the conveniences it provides, "make" does indeed initially look like a step backward in software development.
But, make has a larger history than might first be realized.
To start off with, "make" comes from an era of different, mostly incompatible-at-the-binary-level Unixes. They were incompatible at the binary level because these different Unixes ran on machines with different architectures and different CPUs.
That means that you couldn't simply download an .EXE and expect that it work. Nor an installer file. There was no "App Store" for these early and architecturally incompatible machines.
Now, even though these machines were incompatible at the hardware binary level, one of the ideas of Unix was that you could abstract away the underlying hardware, and come up with a standard interface that would be "more-or-less" compatible from system to system.
You've heard the expression that "Everything is a file" in Unix? Well that's the abstracted interface! (Well, that and more-or-less-standard API calls to work with those files).
To develop software which would work on Unix, any Unix, regardless of the underlying hardware, you would write code in C, and you would call Unix's more-or-less standard API.
But, this required that you compile your source code for each Unix architecture.
Since C programs typically have multiple files, it made sense to put the compilation commands into a single "batch file" (shell script in Unix parlance).
But, as more time went on, these "batch files"/"shell scripts" were called upon to do more and more. That is, until they evolved into their own mini-programming language (note that you see the same evolution in Windows installers, e.g., NSIS).
But on Unix, because again, there were subtle differences from version to version, these scripts would be called upon to do more and more, such as use additional Unix tools in the compilation process, and that brought additional problems, for example, what if one Unix's version of grep or awk or cat or whatever -- had some feature that was missing in some other version... and what if that feature was required to do some functionality related to the compile/install process?
Anyway, here we see that there's one problem, the lack of binary compatibility amoung Unixes, that creates all of these other problems related to compiling and installing.
A polished turd? Well maybe, but one very necessary to solve those early software development problems... But even as it stands today, there is no standard processor/hardware for Unix/Linux, how do you get your software written for a PC to run on a Mainframe or Supercomputer?
So is it still a turd now that the problems it was meant to address are better understood?
I agree it's far from a perfect solution, but it's sort of "what we have" for those problems...
Can you explain how make can be improved? How make is far from perfect? If you look at newer build systems that aren't wrappers they all follow the same sort of rule based open end declarative language as others.
There are too many things to be improved, e.g. support of simple (enough) cases w/o any scriptish code, getting away of stupid syntaxes (like distinctions of indents with TABs vs. spaces) in makefiles, avoiding being relied on as a command line tool in LTO builds (grep GCC source if you don't know how MAKE is depended on), saner parallelism...
If there are not so many things to be improved, there should not have been so many tools to replace `make`.
6 comments
[ 4.1 ms ] story [ 26.7 ms ] threadBut, make has a larger history than might first be realized.
To start off with, "make" comes from an era of different, mostly incompatible-at-the-binary-level Unixes. They were incompatible at the binary level because these different Unixes ran on machines with different architectures and different CPUs.
That means that you couldn't simply download an .EXE and expect that it work. Nor an installer file. There was no "App Store" for these early and architecturally incompatible machines.
Now, even though these machines were incompatible at the hardware binary level, one of the ideas of Unix was that you could abstract away the underlying hardware, and come up with a standard interface that would be "more-or-less" compatible from system to system.
You've heard the expression that "Everything is a file" in Unix? Well that's the abstracted interface! (Well, that and more-or-less-standard API calls to work with those files).
To develop software which would work on Unix, any Unix, regardless of the underlying hardware, you would write code in C, and you would call Unix's more-or-less standard API.
But, this required that you compile your source code for each Unix architecture.
Since C programs typically have multiple files, it made sense to put the compilation commands into a single "batch file" (shell script in Unix parlance).
But, as more time went on, these "batch files"/"shell scripts" were called upon to do more and more. That is, until they evolved into their own mini-programming language (note that you see the same evolution in Windows installers, e.g., NSIS).
But on Unix, because again, there were subtle differences from version to version, these scripts would be called upon to do more and more, such as use additional Unix tools in the compilation process, and that brought additional problems, for example, what if one Unix's version of grep or awk or cat or whatever -- had some feature that was missing in some other version... and what if that feature was required to do some functionality related to the compile/install process?
Anyway, here we see that there's one problem, the lack of binary compatibility amoung Unixes, that creates all of these other problems related to compiling and installing.
A polished turd? Well maybe, but one very necessary to solve those early software development problems... But even as it stands today, there is no standard processor/hardware for Unix/Linux, how do you get your software written for a PC to run on a Mainframe or Supercomputer?
So is it still a turd now that the problems it was meant to address are better understood?
I agree it's far from a perfect solution, but it's sort of "what we have" for those problems...
If there are not so many things to be improved, there should not have been so many tools to replace `make`.
There isn't? The actual non broken badly designed ones that don't generate a DAG and aren't tied to a language is make, tup, ninja and redo.