En el desarrollo de software , Make es una herramienta de automatización de compilación que crea bibliotecas y programas ejecutables a partir del código fuente mediante la lectura de archivos llamados makefiles que especifican cómo derivar el programa de destino. Aunque también se pueden utilizar entornos de desarrollo integrados y funciones de compilador específicas del lenguaje para gestionar un proceso de compilación, Make sigue siendo ampliamente utilizado, especialmente en Unix y sistemas operativos similares a Unix .
Make no se limita a crear programas. También se puede utilizar para administrar cualquier proyecto en el que algunos archivos deban actualizarse automáticamente desde otros archivos cada vez que los otros archivos cambian.
Make es una de las utilidades de compilación de seguimiento de dependencias más extendidas, principalmente debido a su temprana inclusión en Unix , comenzando con PWB/UNIX 1.0, que presentaba una variedad de herramientas para tareas de desarrollo de software. [1] Fue creado 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 la herramienta. [4]
Feldman se inspiró para escribir Make en la experiencia de un compañero de trabajo al depurar inútilmente un programa suyo donde el ejecutable accidentalmente no se actualizaba con los cambios:
Make se originó con una visita de Steve Johnson (autor de yacc, etc.), irrumpiendo en mi oficina, maldiciendo al Destino que le había 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 solucionarlo. Comenzó con una idea elaborada de un analizador de dependencia, 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 : cosas imprimibles, depurables y comprensibles.— 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 objetivos de compilación 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 compilación modernos.
Make se ha reescrito numerosas veces, incluidas nuevas implementaciones que utilizan el mismo formato de archivo y principios algorítmicos básicos y también proporcionan mejoras no estándar. Ejemplos son:
POSIX incluye la estandarización de las características básicas y el funcionamiento de la utilidad Make, y se implementa con distintos grados de compatibilidad con versiones de Make basadas en Unix. En general, se pueden utilizar archivos MAKE simples entre varias versiones de Make con un éxito razonable. GNU Make, Makepp y algunas versiones de BSD hacen que buscar primero archivos llamados "GNUmakefile", [35] "Makeppfile" [36] y "BSDmakefile" [37] respectivamente, lo que permite colocar archivos MAKE que utilizan archivos definidos por la implementación. comportamiento en lugares separados.
Make se utiliza tradicionalmente para compilar archivos de código fuente (por ejemplo, *.c, *.tsarchivos, etc.) en un tipo de archivo objeto de destino que se puede ejecutar directamente como un ejecutable independiente (como es el caso del código fuente C ) o no (como es el caso). para el código fuente de TypeScript ).
Make no se limita únicamente a archivos de objetos: es aplicable en cualquier caso de uso en el que un conjunto de archivos dependa del contenido de otro conjunto de archivos. Make incluye un mecanismo de dependencia para gestionar correctamente estas relaciones. Un posible caso de uso no relacionado con la programación es detectar un cambio realizado en un archivo de imagen (la fuente) y luego convertir el archivo a algún formato específico, copiar el resultado en un sistema de gestión de contenido y enviar un correo electrónico a un conjunto de usuarios indicando que las acciones fueron realizadas.
Make se invoca con una lista de nombres de objetivos en forma de argumentos de línea de comando :
hacer [ OBJETIVO ... ] Sin argumentos, Make construye el primer objetivo que aparece en su archivo MAKE, que tradicionalmente es un objetivo "falso" simbólico llamado all que no corresponde a ningún archivo almacenado.
Make decide si es necesario regenerar un objetivo comparando los tiempos de modificación de archivos. [38] Esto resuelve el problema de evitar la creación de archivos que ya están actualizados, pero falla cuando un archivo cambia pero su hora de modificación permanece en el pasado. Dichos cambios podrían 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 fuente es futura, se desencadena una reconstrucción innecesaria, lo que puede resultar inconveniente para los usuarios.
Los Makefiles también se utilizan tradicionalmente para proporcionar comandos para automatizar tareas comunes de desarrollo de software . Uno de esos archivos MAKE se llama desde la línea de comando:
make # Sin argumentos se ejecuta primero TARGET
make help # Mostrar OBJETIVOS disponibles
make dist # Crear un archivo de lanzamiento desde el directorio actual
make check # Pruebas unitarias sin instalación Make busca en el directorio actual un archivo MAKE, por ejemplo, GNU Make busca archivos en orden para un archivo llamado GNUmakefile , makefile o Makefile . y luego invoca los objetivos especificados (o predeterminados) de ese archivo.
El lenguaje makefile es similar a la programación declarativa . [40] [41] [42] [43] Esta clase de lenguaje, en el que se describen las condiciones finales necesarias pero el orden en el que se deben tomar las acciones no es importante, a veces resulta confusa para los programadores acostumbrados a la programación imperativa .
Un problema común 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 utilizado en otra. Este problema normalmente se soluciona 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 Makefiles pueden contener cinco tipos de construcciones: [44]
#se utilizan para comentarios .Un archivo MAKE consta de reglas . Cada regla comienza con una línea de dependencia textual que define un destino seguida de dos puntos (:) y, opcionalmente, una enumeración de componentes (archivos u otros destinos) de los que depende el destino. La línea de dependencia está dispuesta 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. [45]
objetivo [objetivo...]: [componente...] Tab ↹[comando 1] . . .Tab ↹[comando n]
Por lo general, cada regla tiene un único objetivo, en lugar de múltiples objetivos.
Por ejemplo, un archivo objeto C .o se crea a partir de archivos .c, por lo que los archivos .c vienen primero (es decir, el destino del archivo objeto específico depende de un archivo fuente C y de los archivos de encabezado ). Debido a que Make en sí no comprende, reconoce ni distingue diferentes tipos de archivos, esto abre la posibilidad de error humano.
Cada línea de dependencia puede ir seguida de una serie de líneas de comando con sangría TAB que definen cómo transformar los componentes (normalmente archivos fuente) en el destino (normalmente la "salida"). Si alguno de los requisitos previos tiene una hora de modificación más reciente que el objetivo, se ejecutan las líneas de comando. La documentación de GNU Make se refiere a los comandos asociados con una regla como una "receta".
El primer comando puede aparecer en la misma línea después de los requisitos previos, separados por un punto y coma,
objetivos : requisitos previos ; dominio Por ejemplo,
Hola : ; @ eco " hola "Make puede decidir por dónde empezar mediante la clasificación topológica .
Cada línea de comando debe comenzar con un carácter de tabulación para ser reconocida como un comando. La tabulación es un carácter de espacio en blanco , pero el carácter de espacio no tiene el mismo significado especial. Esto es problemático, ya que puede que no haya diferencia visual entre una tabulación y una serie de caracteres de espacio. Este aspecto de la sintaxis de los archivos MAKE suele estar sujeto a críticas; Eric S. Raymond lo ha descrito como "uno de los peores errores de diseño en la historia de Unix" [46] y The Unix-Haters Handbook decía que "usar pestañas como parte de la sintaxis es como una de esas trampas de pungee en Los Boinas Verdes ". Feldman explica que la elección fue causada por una solución alternativa a una dificultad de implementación temprana preservada por el deseo de compatibilidad con versiones anteriores de los primeros usuarios:
¿Por qué la pestaña en la columna 1? Yacc era nuevo, Lex era nuevo. Yo tampoco lo había intentado, así que pensé que ésta sería una buena excusa para aprender. Después de enredarme con mi primer intento contra Lex, simplemente hice algo simple con el patrón de pestaña de nueva línea. Funcionó, se quedó. Y luego, unas semanas más tarde, tenía una población de usuarios de aproximadamente una docena, la mayoría de ellos amigos, y no quería arruinar mi base integrada. El resto, lamentablemente, es historia.
—Estuardo Feldman [46]
Creación GNU. desde la versión 3.82, permite la elección de cualquier símbolo (un carácter) como prefijo de receta usando la variable especial .RECIPEPREFIX, por ejemplo:
.RECIPEPREFIX := : todos : :@echo "el símbolo de prefijo de receta está establecido en '$(.RECIPEPREFIX)'" Cada comando se ejecuta mediante una instancia de intérprete de línea de comandos o shell independiente . Dado que los sistemas operativos utilizan diferentes intérpretes de línea de comandos, esto puede generar archivos MAKE no portátiles. Por ejemplo, GNU Make (todos los POSIX Makes) ejecuta comandos con /bin/sh de forma predeterminada, donde normalmente se usan comandos de Unix como cp . En contraste con eso, nmake de Microsoft ejecuta comandos con cmd.exe donde están disponibles comandos por lotes como copiar , pero no necesariamente cp.
Una regla puede omitir la receta. La línea de dependencia puede constar únicamente de componentes que hagan referencia a otros objetivos, por ejemplo:
realclean : limpiar distclean Las líneas de comando de una regla generalmente están dispuestas de manera que generen el objetivo. Un ejemplo: si el archivo.html es más nuevo, se convierte a texto. El contenido del archivo MAKE:
archivo.txt : archivo . html lince -volcar archivo.html > archivo.txt La regla anterior se activaría al realizar actualizaciones "file.txt". En la siguiente invocación, Make normalmente usaría esta regla para actualizar el destino "file.txt" si "file.html" fuera más nuevo.
crear archivo.txtLas líneas de comando pueden tener uno o más de los tres prefijos siguientes:
Alternativamente, se pueden ignorar errores y silenciar el eco mediante los objetivos especiales .IGNOREy .SILENT. [47]
NMAKE de Microsoft tiene reglas predefinidas que se pueden omitir en estos archivos MAKE, por ejemplo .c.obj $(CC)$(CFLAGS)
Un archivo MAKE puede contener definiciones de macros. Las macros generalmente se denominan variables cuando contienen definiciones de cadenas simples, como . Las macros en archivos MAKE se pueden anular en los argumentos de la línea de comandos pasados a la utilidad Make. Las variables de entorno también están disponibles como macros.CC=clang
Las macros permiten a los usuarios especificar los programas invocados y otros comportamientos personalizados durante el proceso de construcción. Por ejemplo, la macro CCse usa frecuentemente en archivos MAKE para referirse a la ubicación de un compilador de C , y es posible que el usuario desee especificar un compilador en particular para usar.
Las nuevas macros (o "variables" simples se definen tradicionalmente con letras mayúsculas:
MACRO = definición Se utiliza una macro expandiéndola. Tradicionalmente esto se hace encerrando su nombre dentro $(). (Omitir los paréntesis lleva a Make a interpretar la siguiente letra después de $como el nombre completo de la variable). Una forma equivalente usa llaves en lugar de paréntesis, es decir ${}, que es el estilo utilizado en los BSD .
NUEVO_MACRO = $( MACRO ) - $( MACRO2 ) Las macros pueden estar compuestas de comandos de shell utilizando el operador de sustitución de comandos , indicado por comillas invertidas ( `).
AAAAMMDD = ` fecha ` El contenido de la definición se almacena "tal cual". Se utiliza la evaluación diferida , lo que significa que las macros normalmente se expanden sólo cuando sus expansiones son realmente necesarias, como cuando se usan en las líneas de comando de una regla. Un ejemplo ampliado:
PAQUETE = paquete VERSIÓN = ` fecha + "%Y.%m.%d" ` ARCHIVO = $( PAQUETE ) - $( VERSIÓN ) dist : # Observe que solo ahora las macros se expanden para que el shell las interprete: # tar -cf paquete-`date +"%Y.%m.%d"`.tartar -cf $( ARCHIVO ) .tar . La sintaxis genérica para anular macros en la línea de comando es:
hacer MACRO = "valor" [ MACRO = "valor" ... ] OBJETIVO [ OBJETIVO ... ] Los Makefiles pueden acceder a cualquiera de una serie de macros internas predefinidas , siendo ?y @las más comunes.
objetivo : componente 1 componente 2 # contiene aquellos componentes que necesitan atención (es decir, SON MÁS JÓVENES que el OBJETIVO actual). eco $? # evalúa el nombre OBJETIVO actual entre los que quedan a la izquierda de los dos puntos. eco $ @ Una expansión de sintaxis algo común es el uso de += , ?= y != en lugar del signo igual. Funciona tanto en BSD como en GNU. [48]
Las reglas de sufijo tienen "objetivos" con nombres en el formulario .FROM.TOy se utilizan para iniciar acciones basadas en la extensión del archivo. En las líneas de comando de las reglas de sufijo, POSIX especifica [49] que la macro interna $<se refiere al primer requisito previo y $@se refiere al objetivo. En este ejemplo, que convierte cualquier archivo HTML en texto, el token de redirección del shell >es parte de la línea de comando, mientras que $<es una macro que hace referencia al archivo HTML:
.SUFIJOS : . TXT . HTML# De .html a .txt .html.txt : lince -dump $< > $@ Cuando se llama desde la línea de comando, el ejemplo anterior se expande.
$ hacer -n archivo.txt lince -volcar archivo.html > archivo.txtLas reglas de sufijos no pueden tener requisitos previos propios. [50] Si tienen alguno, se tratan como archivos normales con nombres inusuales, no como reglas de sufijos. GNU Make admite reglas de sufijos para compatibilidad con archivos MAKE antiguos, pero por lo demás fomenta el uso de reglas de patrones . [51]
Una regla de patrón parece una regla normal, excepto que su destino contiene exactamente un %carácter dentro de la cadena. El objetivo se considera un patrón para hacer coincidir nombres de archivos: puede %coincidir con cualquier subcadena de cero o más caracteres, [52] mientras que otros caracteres solo coinciden con ellos mismos. Los requisitos previos también se utilizan %para mostrar cómo se relacionan sus nombres con el nombre del objetivo.
El ejemplo anterior de una regla de sufijo se parecería a la siguiente regla de patrón:
# De %.html a %.txt %.txt : %. html lince -volcar $< > $@ Los comentarios de una sola línea comienzan con el símbolo de almohadilla (#).
Algunas directivas en archivos MAKE pueden incluir otros archivos MAKE.
La continuación de línea se indica con una \barra invertida al final de una línea.
objetivo: componente \ componente Tab ↹dominio ; \ comando | \ comando canalizadoTab ↹Tab ↹
El archivo MAKE:
PAQUETE = paquete VERSIÓN = ` fecha "+%Y.%m%d%" ` RELEASE_DIR = .. RELEASE_FILE = $( PAQUETE ) - $( VERSIÓN ) # Observe que la variable LOGNAME proviene del entorno en # shells POSIX. # # objetivo: todos - Objetivo predeterminado. No hace nada. all : echo "Hola $( LOGNAME ) , nada que hacer de forma predeterminada" # a veces: echo "Hola ${LOGNAME}, nada que hacer de forma predeterminada" echo "Intenta 'hacer ayuda'" # objetivo: ayuda: muestra objetivos invocables. ayuda : egrep "^# destino:" [ Mm ] akefile # target: list - Lista de archivos fuente : # No funcionará. Cada comando está en un shell separado cd src ls # Correcto, continuación del mismo shell cd src ; \ ls # target: dist - Realizar un lanzamiento. dist : tar -cf $( RELEASE_DIR ) / $( RELEASE_FILE ) && \ gzip -9 $( RELEASE_DIR ) / $( RELEASE_FILE ) .tar A continuación se muestra un archivo MAKE muy simple que, de forma predeterminada (la regla "todos" aparece primero) compila un archivo fuente llamado "helloworld.c" usando el compilador C del sistema y también proporciona un destino "limpio" para eliminar los archivos generados si el usuario deseos de empezar de nuevo. Las $@y $<son dos de las llamadas macros internas (también conocidas como variables automáticas) y representan el nombre de destino y la fuente "implícita", respectivamente. En el siguiente ejemplo, $^se expande a una lista de requisitos previos delimitada por espacios. Hay una serie de otras macros internas. [49] [53]
FLAGS ?= -g todos : hola mundo holamundo : holamundo . o # Los comandos comienzan con TAB, no con espacios $( CC ) $( LDFLAGS ) -o $@ $^ holamundo.o : holamundo . c $( CC ) $( CFLAGS ) -c -o $@ $< limpio : FRC $( RM ) holamundo holamundo.o # Este pseudoobjetivo hace que todos los objetivos que dependen de FRC # se rehagan incluso en caso de que exista un archivo con el nombre del objetivo. # Esto funciona con cualquier implementación make bajo el supuesto de que # no hay ningún archivo FRC en el directorio actual. FRC :Muchos sistemas vienen con macros y reglas de creación predefinidas para especificar tareas comunes, como la compilación basada en el sufijo del archivo. Esto permite a los usuarios omitir las instrucciones reales (a menudo no portátiles) sobre cómo generar el objetivo a partir de las fuentes. En dicho sistema, el archivo MAKE anterior podría modificarse de la siguiente manera:
todos : hola mundo holamundo : holamundo . o $( CC ) $( CFLAGS ) $( LDFLAGS ) -o $@ $^ limpio : FRC $( RM ) holamundo holamundo.o # Esta es una regla de sufijo explícita. Puede omitirse en sistemas # que manejan reglas simples como esta automáticamente. .co : $( CC ) $( CFLAGS ) -c $< FRC : .SUFIJOS : . C
Que "helloworld.o" dependa de "helloworld.c" ahora lo maneja automáticamente Make. En un ejemplo tan simple como el que se ilustra aquí, esto apenas importa, pero el poder real de las reglas de sufijos se vuelve evidente cuando la cantidad de archivos fuente en un proyecto de software comienza a crecer. Sólo hay que escribir una regla para el paso de vinculación y declarar los archivos objeto como requisitos previos. Luego, Make determinará implícitamente cómo crear todos los archivos objeto y buscará cambios en todos los archivos fuente.
Las reglas de sufijos simples funcionan bien siempre que los archivos fuente no dependan entre sí ni de otros archivos, como los archivos de encabezado. Otra ruta para simplificar el proceso de construcción es utilizar las llamadas reglas de coincidencia de patrones que se pueden combinar con la generación de dependencias asistida por el compilador. Como ejemplo final que requiere el compilador gcc y GNU Make, aquí hay un archivo MAKE genérico que compila todos los archivos C en una carpeta en los archivos objeto correspondientes y luego los vincula al ejecutable final. Antes de que se realice la compilación, las dependencias se recopilan en un formato compatible con archivos MAKE en un archivo oculto ".depend" que luego se incluye en el archivo MAKE. Los programas portátiles deben evitar las construcciones utilizadas a continuación.
# Archivo GNUMake genérico# Solo un fragmento para detener la ejecución bajo otros comandos make(1) # que no entenderán estas líneas ifneq (,) Este archivo make requiere GNU Make. terminara si PROGRAM = foo C_FILES := $( comodín *.c ) OBJS := $( patsubst %.c, %.o, $( C_FILES )) CC = cc CFLAGS = -Wall -pedantic LDFLAGS = LDLIBS = -lm todos : $( PROGRAMA ) $(PROGRAMA) : . dependen $( OBJS ) $( CC ) $( CFLAGS ) $( OBJS ) $( LDFLAGS ) -o $( PROGRAMA ) $( LDLIBS ) depender : . depender.depend : cmd = gcc - MM - MF depende $( var ) ; gato depende >> . depender ;.depend : @echo "Generando dependencias..." @ $( foreach var, $( C_FILES ) , $( cmd )) @rm -f depende -incluir .depende# Estas son las reglas de coincidencia de patrones. Además de las # variables automáticas utilizadas aquí, la variable $* que coincide con lo que % representa # puede ser útil en casos especiales. %.o : %. c $( CC ) $( CFLAGS ) -c $< -o $@ % : %. o $( CC ) $( CFLAGS ) -o $@ $< limpio : rm -f .depende $( OBJS ) .PHONY : limpio depende Makefile consta de dependencias y uno olvidado o adicional puede no ser inmediatamente obvio para el usuario y puede provocar errores sutiles en el software generado que son difíciles de detectar. Se pueden utilizar varios enfoques para evitar este problema y mantener sincronizadas las dependencias en el código fuente y los archivos MAKE. Un enfoque es utilizar un compilador para realizar un seguimiento de los cambios de dependencias. Por ejemplo, GCC puede analizar estáticamente el código fuente y producir reglas para el archivo determinado automáticamente mediante el uso de -MMun interruptor. El otro enfoque serían los archivos MAKE o herramientas de terceros que generarían archivos MAKE con dependencias (por ejemplo, la cadena de herramientas Automake del Proyecto GNU , puede hacerlo automáticamente).
Otro enfoque es utilizar herramientas de metaconstrucción como CMake , Meson , etc.
En el mantenimiento general de DWB, hemos utilizado el sistema de control de código fuente y la utilidad make proporcionada por el sistema operativo interactivo PWB/UNIX*.
.svg/1280px-Free_and_open-source_software_logo_(2009).svg.png){kind=logo}
{{cite web}}: Mantenimiento CS1: bot: estado de la URL original desconocido ( enlace )En make se proporcionan inclusión de archivos Makefile, estructuras condicionales y bucles for que recuerdan al lenguaje de programación C.
