), storming into my office, cursing the Fates that had caused him to waste a morning debugging a correct program (bug had been fixed, file hadn't been compiled, cc *.o was therefore unaffected).
As I had spent a part of the previous evening coping with the same disaster on a project I was working on, the idea of a tool to solve it came up.
It began with an elaborate idea of a dependency analyzer, boiled down to something much simpler, and turned into Make that weekend.
Make is widely used in part due to its early inclusion in Unix, starting with PWB/UNIX 1.0, which featured a variety of software development tools.
Also, if a source file's timestamp is in the future, make repeatedly triggers unnecessary actions, causing longer build time.
The makefile language is partially declarative programming where end conditions are described but the order in which actions are to be taken is not.
Eric S. Raymond describes it as "one of the worst design botches in the history of Unix"[46] and The Unix-Haters Handbook said "using tabs as part of the syntax is like one of those pungee [sic] stick traps in The Green Berets".
Feldman explains the choice as caused by a workaround for an early implementation difficulty, and preserved by a desire for backward compatibility with the very first users: Why the tab in column 1?
The rest, sadly, is history.GNU Make since version 3.82 allows the choice of any symbol (one character) as the recipe prefix using the .RECIPEPREFIX special variable: Each command is executed in a separate shell.
A command can have one or more of the following prefixes (after the tab): Ignoring errors and silencing echo can alternatively be obtained via the special targets .IGNORE and .SILENT.
The latter is safer since omitting the parentheses leads to Make interpreting the next letter after the $ as the entire variable name.
A common syntax when defining macros, which works on BSD and GNU Make, is to use +=, ?=, and != instead of the equal sign (=).
[49] Suffix rules have "targets" with names in the form .FROM.TO and are used to launch actions based on file extension.
In this example, which converts any HTML file into text, the shell redirection token > is part of the command line, whereas $< is a macro referring to the HTML file: When called from the command line, the example above expands: Suffix rules cannot have any prerequisites of their own.
The $@ and $< are two of the so-called internal macros (also known as automatic variables) and stand for the target name and "implicit" source, respectively.
[50][54] Many systems come with predefined Make rules and macros to specify common tasks such as compilation based on file suffix.
In such a simple example as the one illustrated here this hardly matters, but the real power of suffix rules becomes evident when the number of source files in a software project starts to grow.
Another route to simplify the build process is to use so-called pattern matching rules that can be combined with compiler-assisted dependency generation.
Before compilation takes place, dependencies are gathered in makefile-friendly format into a hidden file ".depend" that is then included to the makefile.
Makefile consist of dependencies and a forgotten or an extra one may not be immediately obvious to the user and may result in subtle bugs in the generated software that are hard to catch.
One approach is by using compiler to keep track of dependencies changes .e.g GCC can statically analyze the source code and produce rules for the given file automatically by using -MM switch.