Hacer (software)

Standard UNIX utility for build automation

Fabricar

Paradigma	macro , declarativo
Diseñada por	Stuart Feldman
Apareció por primera vez	Abril de 1976 ; Hace 45 años (1976-04)
Lenguaje de implementación	C
SO	Inferno , tipo Unix
Formatos de archivo	Makefile
Implementaciones importantes
BSD, GNU, nmake
Dialectos
Marca BSD, marca GNU, Microsoft nmake
Influenciado
Ant , Rake , MSBuild y otros

En el desarrollo de software , Make es una automatización de acumulación herramienta que automáticamente genera los programas ejecutables y bibliotecas de código fuente mediante la lectura de archivos llamados Makefile que especifican cómo derivar el programa de destino. A pesar de los entornos de desarrollo integrados y de lenguaje específico de compilador características también se pueden utilizar para gestionar un proceso de construcción, Hacer sigue siendo ampliamente utilizados, sobre todo en Unix y Unix-como sistemas operativos .

Además de crear programas, Make se puede utilizar para gestionar cualquier proyecto en el que algunos archivos deban actualizarse automáticamente desde otros siempre que los otros cambien.

Origen

Ahora hay una serie de utilidades de compilación de seguimiento de dependencias, pero Make es una de las más extendidas, principalmente debido a su inclusión en Unix , comenzando con PWB / UNIX 1.0, que presentaba una variedad de herramientas dirigidas a tareas de desarrollo de software. ^[1] Fue creado originalmente por Stuart Feldman en abril de 1976 en Bell Labs . ^{[2] [3] [1]} Feldman recibió el premio ACM Software System Award 2003 por la creación de esta amplia herramienta. ^[4]

Feldman se inspiró para escribir Make por la experiencia de un compañero de trabajo al depurar inútilmente un programa suyo en el que el ejecutable no se actualizaba accidentalmente con cambios:

Make se originó con una visita de Steve Johnson (autor de yacc, etc.), irrumpiendo en mi oficina, maldiciendo a los Fates que le habían hecho perder una mañana depurando un programa correcto (el error se había solucionado, el archivo no se había compilado, cc *.opor lo tanto, no se vio afectado). Como había pasado parte de la noche anterior lidiando con el mismo desastre en un proyecto en el que estaba trabajando, surgió la idea de una herramienta para resolverlo. Comenzó con una idea elaborada de un analizador de dependencias, se redujo a algo mucho más simple y se convirtió en Make ese fin de semana. El uso de herramientas que aún estaban húmedas era parte de la cultura. Los Makefiles eran archivos de texto, no binarios codificados mágicamente, porque ese era el espíritu de Unix: material imprimible, depurable y comprensible.

-  Stuart Feldman, El arte de la programación Unix , Eric S. Raymond 2003

Antes de la introducción de Make, el sistema de compilación Unix consistía más comúnmente en scripts de shell "make" e "install" dependientes del sistema operativo que acompañaban al código fuente de su programa. Poder combinar los comandos para los diferentes objetivos en un solo archivo y poder abstraer el seguimiento de dependencias y el manejo de archivos fue un paso importante en la dirección de los entornos de construcción modernos.

Derivados

Make ha pasado por una serie de reescrituras , incluida una serie de variantes desde cero que utilizaban el mismo formato de archivo y principios algorítmicos básicos y también proporcionaban una serie de sus propias mejoras no estándar. Algunos de ellos son:

• Sun DevPro Make apareció en 1986 con SunOS-3.2. Con SunOS-3.2, se entregó como programa opcional; con SunOS-4.0, SunPro Make se convirtió en el programa Make predeterminado. ^{[5] [Se necesita una mejor fuente ]} En diciembre de 2006, Sun DevPro Make se convirtió en código abierto como parte de los esfuerzos para abrir Solaris . ^{[6] [7]}
• dmake o Marca distribuida que venía con Sun Solaris Studio como Marca predeterminada, pero no la predeterminada en el sistema operativo Solaris (SunOS). Originalmente se requería para construir OpenOffice, pero en 2009 ^[8] el sistema de construcción fue reescrito para usar GNU Make. Si bien Apache OpenOffice todavía contiene una mezcla de ambos sistemas de compilación, ^[9] LibreOffice, mucho más desarrollado, ahora solo usa el modernizado "gbuild". ^[8]
• BSD Make ( pmake , ^[10] bmake ^[11] o fmake ^[12] ), que se deriva del trabajo de Adam de Boor en una versión de Make capaz de construir objetivos en paralelo , y sobrevive con diversos grados de modificación en FreeBSD , ^{[ 11]} NetBSD ^[13] y OpenBSD . ^{[14] De manera} distintiva, tiene ciclos condicionales e iterativos que se aplican en la etapa de análisis y se pueden usar para construir condicional y programáticamente el archivo MAKE, ^[15] incluida la generación de objetivos en tiempo de ejecución. ^{[ cita requerida ]}
• GNU Make (abreviado gmake ) es la implementación estándar de Make para Linux y macOS. ^[16] Proporciona varias extensiones sobre la Marca original, como condicionales. También proporciona muchas funciones integradas que se pueden usar para eliminar la necesidad de utilizar scripts de shell en las reglas del archivo make, así como para manipular las variables establecidas y utilizadas en el archivo make. ^[17] Por ejemplo, la función foreach puede usarse para iterar sobre una lista de valores, como los nombres de archivos en un directorio dado. ^[18] GNU Make es necesario para construir muchos sistemas de software, incluido GCC (desde la versión 3.4 ^[19] ), el kernel de Linux, ^{[20] [21]}Apache OpenOffice, ^[9] LibreOffice, ^[8] y Mozilla Firefox . ^[22]
• Rocky Bernstein's Remake ^[23] es una bifurcación de GNU Make y proporciona varias extensiones sobre GNU Make, como mejores informes de ubicación y ubicación de errores, seguimiento de ejecución, creación de perfiles de ejecución y contiene un depurador.
• Nmake ^{[24] de} Glenn Fowler no está relacionado con el programa de Microsoft del mismo nombre. Su entrada es similar a Make, pero no compatible. Este programa proporciona accesos directos y funciones integradas, que según sus desarrolladores reducen el tamaño de los archivos MAKE en un factor de 10.
• Microsoft nmake , una herramienta de línea de comandos que normalmente forma parte de Visual Studio . ^[25] Soporta directivas de preprocesador como inclusiones y expresiones condicionales que usan variables establecidas en la línea de comandos o dentro de los archivos MAKE. ^{[26] [27] Las} reglas de inferencia difieren de Make; por ejemplo, pueden incluir rutas de búsqueda. ^[28] La herramienta Make suministrada con los productos Embarcadero tiene una opción de línea de comandos que "hace que MAKE imite el NMAKE de Microsoft". ^[29] . La herramienta Jom de Qt Project es un clon de nmake. ^[30]
• Mk reemplazó a Make in Research Unix , a partir de la versión 9. ^[31] Un rediseño de la herramienta original por el programador de Bell Labs, Andrew G. Hume, presenta una sintaxis diferente. Mk se convirtió en la herramienta de construcción estándar en Plan 9 , el sucesor previsto de Bell Labs para Unix. ^[32]
• Kati es el reemplazo de GNU Make de Google, que se utiliza en las compilaciones del sistema operativo Android . Traduce el archivo MAKE a ninja para compilaciones incrementales más rápidas. ^[33]

POSIX incluye la estandarización de las características básicas y el funcionamiento de la utilidad Make, y se implementa con diversos grados de integridad en las versiones de Make basadas en Unix. En general, se pueden usar archivos MAKE simples entre varias versiones de Make con un éxito razonable. GNU Make, Makepp y algunas versiones de BSD. Por defecto, buscar primero los archivos llamados "GNUmakefile", ^[34] "Makeppfile" ^[35] y "BSDmakefile" ^[36] respectivamente, lo que permite poner archivos MAKE que utilizan archivos de implementación definidos. comportamiento en lugares separados.

Comportamiento

Make se utiliza normalmente para crear programas ejecutables y bibliotecas a partir del código fuente. Sin embargo, en general, Make es aplicable a cualquier proceso que implique la ejecución de comandos arbitrarios para transformar un archivo de origen en un resultado de destino. Por ejemplo, Make podría usarse para detectar un cambio realizado en un archivo de imagen (la fuente) y las acciones de transformación podrían ser convertir el archivo a algún formato específico, copiar el resultado en un sistema de administración de contenido y luego enviar un correo electrónico a un conjunto predefinido de usuarios que indica que se realizaron las acciones anteriores.

Make se invoca con una lista de nombres de archivos de destino para construir como argumentos de línea de comandos :

hacer [ OBJETIVO ... ]

Sin argumentos, Make construye el primer objetivo que aparece en su archivo MAKE, que tradicionalmente es un objetivo simbólico "falso" llamado all .

Make decide si es necesario volver a generar un objetivo comparando los tiempos de modificación del archivo. ^[37] Esto resuelve el problema de evitar la construcción de archivos que ya están actualizados, pero falla cuando un archivo cambia pero su tiempo de modificación permanece en el pasado. Dichos cambios pueden deberse a la restauración de una versión anterior de un archivo fuente, o cuando un sistema de archivos de red es una fuente de archivos y su reloj o zona horaria no está sincronizado con la máquina que ejecuta Make. El usuario debe manejar esta situación forzando una compilación completa. Por el contrario, si la hora de modificación de un archivo de origen es en el futuro, desencadena una reconstrucción innecesaria, lo que puede incomodar a los usuarios.

Los Makefiles se utilizan tradicionalmente para compilar código (* .c, * .cc, * .C, etc.), pero también se pueden utilizar para proporcionar comandos para automatizar tareas comunes. Uno de esos archivos MAKE se llama desde la línea de comando:

make # Sin argumento se ejecuta primero TARGET
make help  # Muestra los OBJETIVOS disponibles
make dist # Crea un archivo de lanzamiento desde el directorio actual

Makefile

Make busca en el directorio actual para el makefile a usar, por ejemplo GNU Make busca archivos en orden para un archivo llamado GNUmakefile , makefile o Makefile y luego ejecuta el destino especificado (o predeterminado) desde (solo) ese archivo.

El lenguaje Makefile es similar a la programación declarativa . ^{[38] [39] [40]} Esta clase de lenguaje, en la que se describen las condiciones finales necesarias pero el orden en el que se deben tomar las acciones no es importante, a veces confunde a los programadores acostumbrados a la programación imperativa .

Un problema en la automatización de la construcción es la adaptación de un proceso de construcción a una plataforma determinada . Por ejemplo, es posible que el compilador utilizado en una plataforma no acepte las mismas opciones que el que se utiliza en otra. Make no lo maneja bien. Este problema generalmente se maneja generando instrucciones de compilación específicas de la plataforma, que a su vez son procesadas por Make. Las herramientas comunes para este proceso son Autoconf , CMake o GYP (o NG más avanzado ).

Los archivos Makefiles pueden contener cinco tipos de cosas: ^[41]

1. Una regla explícita dice cuándo y cómo rehacer uno o más archivos, llamados objetivos de la regla. Enumera los otros archivos de los que dependen los objetivos, denominados requisitos previos del objetivo, y también puede proporcionar una receta para usar para crear o actualizar los objetivos.
2. Una regla implícita dice cuándo y cómo rehacer una clase de archivos según sus nombres. Describe cómo un objetivo puede depender de un archivo con un nombre similar al objetivo y proporciona una receta para crear o actualizar dicho objetivo.
3. Una definición de variable es una línea que especifica un valor de cadena de texto para una variable que se puede sustituir en el texto más adelante.
4. Una directiva es una instrucción para que make haga algo especial mientras lee el archivo MAKE, como leer otro archivo MAKE.
5. Las líneas que comienzan con #se utilizan para comentarios .

Reglas

Un archivo MAKE consta de reglas . Cada regla comienza con una línea de dependencia textual que define un objetivo seguido de dos puntos (:) y, opcionalmente, una enumeración de componentes (archivos u otros objetivos) de los que depende el objetivo. La línea de dependencia está organizada de modo que el objetivo (mano izquierda de los dos puntos) dependa de los componentes (mano derecha de los dos puntos). Es común referirse a los componentes como requisitos previos del objetivo. ^[42]

objetivo [objetivo ...]: [componente ...] Tab ↹[comando 1] . . .Tab ↹[comando n]

Por lo general, cada regla tiene un único objetivo único, en lugar de varios objetivos.

Por ejemplo, un archivo de objeto C .o se crea a partir de archivos .c, por lo que los archivos .c son lo primero (es decir, el destino del archivo de objeto específico depende de un archivo de origen C y archivos de encabezado ). Debido a que Make en sí mismo no comprende, reconoce o distingue diferentes tipos de archivos, esto abre una posibilidad de error humano. Una dependencia olvidada o adicional puede no ser inmediatamente obvia y puede resultar en errores sutiles en el software generado. Es posible escribir archivos MAKE que generan estas dependencias llamando a herramientas de terceros, y algunos generadores de archivos MAKE, como la cadena de herramientas Automake proporcionada por el Proyecto GNU , pueden hacerlo automáticamente.

Each dependency line may be followed by a series of TAB indented command lines which define how to transform the components (usually source files) into the target (usually the "output"). If any of the prerequisites has a more recent modification time than the target, the command lines are run. The GNU Make documentation refers to the commands associated with a rule as a "recipe".

The first command may appear on the same line after the prerequisites, separated by a semicolon,

targets : prerequisites ; command

for example,

hello: ; @echo "hello"

Make can decide where to start through topological sorting.

Each command line must begin with a tab character to be recognized as a command. The tab is a whitespace character, but the space character does not have the same special meaning. This is problematic, since there may be no visual difference between a tab and a series of space characters. This aspect of the syntax of makefiles is often subject to criticism; it has been described by Eric S. Raymond as "one of the worst design botches in the history of Unix"^[43] and The Unix-Haters Handbook said "using tabs as part of the syntax is like one of those pungee stick traps in The Green Berets". Feldman explains the choice as caused by a workaround for an early implementation difficulty preserved by a desire for backward compatibility with the very first users:

Why the tab in column 1? Yacc was new, Lex was brand new. I hadn't tried either, so I figured this would be a good excuse to learn. After getting myself snarled up with my first stab at Lex, I just did something simple with the pattern newline-tab. It worked, it stayed. And then a few weeks later I had a user population of about a dozen, most of them friends, and I didn't want to screw up my embedded base. The rest, sadly, is history.

— Stuart Feldman^[43]

However, the GNU Make since version 3.82 allows to choose any symbol (one character) as the recipe prefix using the .RECIPEPREFIX special variable, for example:

.RECIPEPREFIX := :all::@echo "recipe prefix symbol is set to '$(.RECIPEPREFIX)'"

Each command is executed by a separate shell or command-line interpreter instance. Since operating systems use different command-line interpreters this can lead to unportable makefiles. For instance, GNU Make (all POSIX Makes) by default executes commands with /bin/sh, where Unix commands like cp are normally used. In contrast to that, Microsoft's nmake executes commands with cmd.exe where batch commands like copy are available but not necessarily cp.

A rule may have no command lines defined. The dependency line can consist solely of components that refer to targets, for example:

realclean: clean distclean

The command lines of a rule are usually arranged so that they generate the target. An example: if file.html is newer, it is converted to text. The contents of the makefile:

file.txt: file.htmllynx -dump file.html > file.txt

The above rule would be triggered when Make updates "file.txt". In the following invocation, Make would typically use this rule to update the "file.txt" target if "file.html" were newer.

make file.txt

Command lines can have one or more of the following three prefixes:

• a hyphen-minus (-), specifying that errors are ignored
• an at sign (@), specifying that the command is not printed to standard output before it is executed
• a plus sign (+), the command is executed even if Make is invoked in a "do not execute" mode

Ignoring errors and silencing echo can alternatively be obtained via the special targets .IGNORE and .SILENT.^[44]

Microsoft's NMAKE has predefined rules that can be omitted from these makefiles, e.g. c.obj $(CC)$(CFLAGS).

Macros

A makefile can contain definitions of macros. Macros are usually referred to as variables when they hold simple string definitions, like {{{1}}}. Macros in makefiles may be overridden in the command-line arguments passed to the Make utility. Environment variables are also available as macros.

Macros allow users to specify the programs invoked and other custom behavior during the build process. For example, the macro CC is frequently used in makefiles to refer to the location of a C compiler, and the user may wish to specify a particular compiler to use.

New macros (or simple "variables") are traditionally defined using capital letters:

MACRO = definition

A macro is used by expanding it. Traditionally this is done by enclosing its name inside $(). (Omitting the parentheses leads to Make interpreting the next letter after the $ as the entire variable name.) An equivalent form uses curly braces rather than parentheses, i.e. ${}, which is the style used in the BSDs.

NEW_MACRO = $(MACRO)-$(MACRO2)

Macros can be composed of shell commands by using the command substitution operator, denoted by backticks (`).

YYYYMMDD = ` date `

The content of the definition is stored "as is". Lazy evaluation is used, meaning that macros are normally expanded only when their expansions are actually required, such as when used in the command lines of a rule. An extended example:

PACKAGE = packageVERSION = ` date +"%Y.%m%d" `ARCHIVE = $(PACKAGE)-$(VERSION)dist:# Notice that only now macros are expanded for shell to interpret:# tar -cf package-`date +"%Y%m%d"`.tartar -cf $(ARCHIVE).tar .

The generic syntax for overriding macros on the command line is:

make MACRO="value" [MACRO="value" ...] TARGET [TARGET ...]

Makefiles can access any of a number of predefined internal macros, with ? and @ being the most common.

target: component1 component2# contains those components which need attention (i.e. they ARE YOUNGER than current TARGET).echo $? # evaluates to current TARGET name from among those left of the colon.echo $@

A somewhat common syntax expansion is the use of +=, ?=, and != instead of the equal sign. It works on BSD and GNU makes alike.^[45]

Suffix rules

Suffix rules have "targets" with names in the form .FROM.TO and are used to launch actions based on file extension. In the command lines of suffix rules, POSIX specifies^[46] that the internal macro $< refers to the first prerequisite and $@ refers to the target. 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:

.SUFFIXES: .txt .html# From .html to .txt.html.txt:lynx -dump $< > $@

When called from the command line, the above example expands.

$ make -n file.txt
lynx -dump file.html > file.txt

Pattern rules

Suffix rules cannot have any prerequisites of their own.^[47] If they have any, they are treated as normal files with unusual names, not as suffix rules. GNU Make supports suffix rules for compatibility with old makefiles but otherwise encourages usage of pattern rules.^[48]

A pattern rule looks like an ordinary rule, except that its target contains exactly one % character within the string. The target is considered a pattern for matching file names: the % can match any substring of zero or more characters,^[49] while other characters match only themselves. The prerequisites likewise use % to show how their names relate to the target name.

The above example of a suffix rule would look like the following pattern rule:

# From %.html to %.txt%.txt : %.html	lynx -dump $< > $@

Other elements

Single-line comments are started with the hash symbol (#).

Some directives in makefiles can include other makefiles.

Line continuation is indicated with a backslash \ character at the end of a line.

 target: component \ component Tab ↹command ; \ Tab ↹command | \ Tab ↹piped-command

Example makefiles

The makefile:

PACKAGE = packageVERSION = ` date "+%Y.%m%d%" `RELEASE_DIR = ..RELEASE_FILE = $(PACKAGE)-$(VERSION)# Notice that the variable LOGNAME comes from the environment in# POSIX shells.## target: all - Default target. Does nothing.all:echo "Hello $(LOGNAME), nothing to do by default"# sometimes: echo "Hello ${LOGNAME}, nothing to do by default"echo "Try 'make help'"# target: help - Display callable targets.help:egrep "^# target:" [Mm]akefile# target: list - List source fileslist:# Won't work. Each command is in separate shellcd src	ls# Correct, continuation of the same shellcd src; \ls# target: dist - Make a release.dist:tar -cf $(RELEASE_DIR)/$(RELEASE_FILE) && \gzip -9 $(RELEASE_DIR)/$(RELEASE_FILE).tar

Below is a very simple makefile that by default (the "all" rule is listed first) compiles a source file called "helloworld.c" using the system's C compiler and also provides a "clean" target to remove the generated files if the user desires to start over. 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. In the example below, $^ expands to a space delimited list of the prerequisites. There are a number of other internal macros.^[46][50]

CFLAGS ?= -gall: helloworldhelloworld: helloworld.o# Commands start with TAB not spaces$(CC) $(LDFLAGS) -o $@ $^helloworld.o: helloworld.c$(CC) $(CFLAGS) -c -o $@ $<clean: FRC$(RM) helloworld helloworld.o# This pseudo target causes all targets that depend on FRC# to be remade even in case a file with the name of the target exists.# This works with any make implementation under the assumption that# there is no file FRC in the current directory.FRC:

Many systems come with predefined Make rules and macros to specify common tasks such as compilation based on file suffix. This lets users omit the actual (often unportable) instructions of how to generate the target from the source(s). On such a system the above makefile could be modified as follows:

all: helloworldhelloworld: helloworld.o$(CC) $(CFLAGS) $(LDFLAGS) -o $@ $^clean: FRC$(RM) helloworld helloworld.o# This is an explicit suffix rule. It may be omitted on systems# that handle simple rules like this automatically..c.o:$(CC) $(CFLAGS) -c $<FRC:.SUFFIXES: .c

That "helloworld.o" depends on "helloworld.c" is now automatically handled by Make. 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. One only has to write a rule for the linking step and declare the object files as prerequisites. Make will then implicitly determine how to make all the object files and look for changes in all the source files.

Simple suffix rules work well as long as the source files do not depend on each other and on other files such as header files. Another route to simplify the build process is to use so-called pattern matching rules that can be combined with compiler-assisted dependency generation. As a final example requiring the gcc compiler and GNU Make, here is a generic makefile that compiles all C files in a folder to the corresponding object files and then links them to the final executable. Before compilation takes place, dependencies are gathered in makefile-friendly format into a hidden file ".depend" that is then included to the makefile. Portable programs ought to avoid constructs used below.

# Generic GNUMakefile# Just a snippet to stop executing under other make(1) commands# that won't understand these linesifneq (,)This makefile requires GNU Make.endifPROGRAM = fooC_FILES := $(wildcard *.c)OBJS := $(patsubst %.c, %.o, $(C_FILES))CC = ccCFLAGS = -Wall -pedanticLDFLAGS =LDLIBS = -lmall: $(PROGRAM)$(PROGRAM): .depend $(OBJS)$(CC) $(CFLAGS) $(OBJS) $(LDFLAGS) -o $(PROGRAM) $(LDLIBS)depend: .depend.depend: cmd = gcc -MM -MF depend $(var); cat depend >> .depend;.depend:@echo "Generating dependencies..."@$(foreach var, $(C_FILES), $(cmd))@rm -f depend-include .depend# These are the pattern matching rules. In addition to the automatic# variables used here, the variable $* that matches whatever % stands for# can be useful in special cases.%.o: %.c$(CC) $(CFLAGS) -c $< -o $@%: %.o$(CC) $(CFLAGS) -o $@ $<clean:rm -f .depend $(OBJS).PHONY: clean depend

See also

• List of build automation software
• Dependency graph

References

1. Thompson, T. J. (November 1980). "Designer's Workbench: Providing a Production Environment". Bell System Technical Journal. 59 (9): 1811–1825. doi:10.1002/j.1538-7305.1980.tb03063.x. S2CID 27213583. In the general maintenance of DWB, we have used the Source Code Control System and make utility provided by the PWB/UNIX* interactive operating system.
2. "V7/usr/src/cmd/make/ident.c". tuhs.org. 1 September 2013. Archived from the original on 1 September 2013. Retrieved 18 March 2018.
3. Feldman, S. I. (April 1979). "Make --- A Program for Maintaining Computer Programs". Software: Practice and Experience. 9 (4): 255–265. CiteSeerX 10.1.1.39.7058. doi:10.1002/spe.4380090402.
4. Matthew Doar (2005). Practical Development Environments. O'Reilly Media. p. 94. ISBN 978-0-596-00796-6.
5. "Google Groups". arquivo.pt. Archived from the original on 22 January 2011. Retrieved 18 March 2018.
6. "OpenSolaris at Two (Jim Grisanzio)". 12 December 2013. Archived from the original on 12 December 2013. Retrieved 18 March 2018.
7. Grisanzio, Jim. The OpenSolaris Story.
8. "Development/Gbuild - The Document Foundation Wiki". wiki.documentfoundation.org. Retrieved 18 March 2018.
9. "Apache OpenOffice Building Guide - Apache OpenOffice Wiki". wiki.openoffice.org. Retrieved 18 March 2018.
10. FreeBSD 2.0.5 Make Source Code, 1993
11. https://www.freebsd.org/cgi/man.cgi?query=bmake&sektion=1
12. https://manpages.debian.org/jessie/freebsd-buildutils/fmake.1
13. "make". NetBSD Manual Pages. Retrieved 9 July 2020.
14. "make(1) - OpenBSD manual pages". man.openbsd.org. Retrieved 18 March 2018.
15. "make". FreeBSD. Retrieved 9 July 2020. Makefile inclusion, conditional structures and for loops reminiscent of the C programming language are provided in make.
16. Arnold Robbins (2005), Unix in a Nutshell, Fourth Edition, O'Reilly
17. "8. Functions for Transforming Text", GNU make, Free Software Foundation, 2013
18. "8.5 The foreach Function", GNU make, Free Software Foundation, 2013
19. "GCC 3.4 Release Series Changes, New Features, and Fixes". Free Software Foundation. 2006.
20. Javier Martinez Canillas (December 26, 2012). "Kbuild: the Linux Kernel Build System". Linux Journal.
21. Greg Kroah-Hartman (2006), Linux Kernel in a Nutshell, O'Reilly
22. "Build Instructions".
23. Rocky Bernstein. "Remake – GNU Make with comprehensible tracing and a debugger".
24. Glenn Fowler (January 4, 2012). "nmake Overview". Information and Software Systems Research, AT&T Labs Research. Archived from the original on September 2, 2015. Retrieved May 26, 2014.
25. "NMAKE Reference Visual Studio 2015". Microsoft. 2015.
26. "Makefile Preprocessing Directives". 2014.
27. "Makefile Preprocessing Operators". Microsoft. 2014.
28. "Search Paths in Rules". Microsoft. 2014.
29. "MAKE". CodeGear(TM). 2008.
30. "Jom - Qt Wiki". Qt Project. 2021.
31. McIlroy, M. D. (1987). A Research Unix reader: annotated excerpts from the Programmer's Manual, 1971–1986 (PDF) (Technical report). Bell Labs. CSTR 139.
32. Hume, Andrew G.; Flandrena, Bob (2002). "Maintaining files on Plan 9 with Mk". Plan 9 Programmer’s Manual. AT&T Bell Laboratories. Archived from the original on July 11, 2015.
33. "google/kati: An experimental GNU make clone". GitHub. 30 November 2020.
34. "GNU 'make'". Free Software Foundation.
35. "Makepp".
36. "Free BSD make".
37. How to sort Linux ls command file output Archived September 13, 2016, at the Wayback Machine
38. an overview on dsls Archived October 23, 2007, at the Wayback Machine, 2007/02/27, phoenix wiki
39. Re: Choreography and REST Archived September 12, 2016, at the Wayback Machine, from Christopher B Ferris on 2002-08-09
40. Target Junior Makefiles Archived January 7, 2010, at the Wayback Machine, Andrew W. Fitzgibbon and William A. Hoffman
41. 3.1 What Makefiles Contain, GNU make, Free Software Foundation
42. "Prerequisite Types (GNU make)". GNU.org. GNU Project. Retrieved 15 December 2020.
43. "Chapter 15. Tools: make: Automating Your Recipes", The Art of Unix Programming, Eric S. Raymond 2003
44. make – Commands & Utilities Reference, The Single UNIX Specification, Issue 7 from The Open Group
45. make(1) – FreeBSD General Commands Manual
46. "make". www.opengroup.org. Retrieved 18 March 2018.
47. "GNU make manual: suffix rules". Free Software Foundation.
48. "GNU make manual: pattern rules". Free Software Foundation.
49. See section Pattern Matching Rules in the SunPro man page Archived May 29, 2014, at the Wayback Machine
50. Automatic Variables Archived April 25, 2016, at the Wayback Machine GNU `make'

External links

Wikibooks has a book on the topic of: make

• GNU Make homepage
• Practical Makefiles, by Example
• Writing and Debugging a Makefile
• "Ask Mr. Make" series of article about GNU Make
• Managing Projects with GNU make -- 3.xth edition
• What is wrong with make?
• What’s Wrong With GNU make?
• Recursive Make Considered Harmful
• Advanced Auto-Dependency Generation.
• Using NMake
• Make7 - A portable open source make utility written in Seed7
• Microsoft's NMAKE predefined rules.