makepp_rules: en línea en la nube

PROGRAMA:

NOMBRE

makepp_rules - Cómo decirle a makepp que construya algo

DESCRIPCIÓN

?: &,
-,
@, B: : build_cache,
: build_check, D: :envío, E: : env, I: "ignore_error",
:incluir, L: :última oportunidad, M: maquillaje, N: "noecho", P: : analizador,
"perl", S: :firma

Una regla es lo que le dice a makepp cómo construir un archivo o una clase de archivos. Makepp apoya el
la misma sintaxis de reglas que otras implementaciones de make, más algunas adiciones propias.

Una regla tiene el formato general

target_expression: dependency_expression [: argumentos opcionales]
acciones

La lista de objetivos no puede contener variables automáticas (excepto "$ (foreach)"). los
La lista de dependencias puede contener solo variables automáticas que se refieren al objetivo (es decir,
"$ (salida)", "$ (salidas)" o sus sinónimos). La acción puede contener cualquier
variables.

Si makepp decide que la regla debe ejecutarse, se ejecuta cada línea de la regla
secuencialmente, y si alguno devuelve un estado distinto de cero, el resto no se ejecuta (y
makepp aborta con un error a menos que haya especificado la opción "-k" en la línea de comando).
Cada acción debe tener una sola línea. Si una acción es demasiado larga para escribirla convenientemente en un
línea única, puede dividirla en varias líneas y poner una barra invertida para indicar que la
varias líneas deben combinarse en una.

Para distinguir las acciones de la siguiente regla, la acción debe tener una sangría más
que la línea que contiene los destinos y las dependencias. A diferencia de otras implementaciones de
make, makepp realmente no le importa cuánto sangra o si usa tabulaciones
en lugar de espacios. Para mantener la compatibilidad con versiones anteriores de la marca tradicional, las reglas
makepp utiliza para decidir cuándo terminan las acciones y comienza la siguiente regla son algo complicadas:

· La primera línea de acción debe tener más sangría que la línea que contiene el objetivo.

· Si una línea tiene sangría con un carácter de tabulación o con 8 espacios o más, se considera
una línea de acción.

· Una línea en blanco o una línea de comentario con el carácter "#" en el margen derecho termina el
regla, a menos que la siguiente línea que no esté en blanco tenga más de 8 espacios (o más de una
lengüeta).

· Si una línea tiene tanto o más sangría que la primera línea de acción, entonces es
considerado una línea de acción adicional.

Hay algunos elementos de acción especiales:

& Este símbolo debe ir seguido de un nombre de comando y cualquier número de argumentos. Cascarón
la sintaxis no se entiende completamente aquí, solo comillas simples y dobles y barra invertida
personajes dentro, como a lo largo de makepp. El nombre del comando conduce a una función
"C_nombre" para ser llamado con las cadenas restantes como argumentos. Si tal función puede
no se encuentra, esto es idéntico a llamar a "ejecutar" desde un bloque "perl".

Esto permite llamar de manera eficiente a un comando integrado, proporcionado por un archivo MAKE o externo.
Se ha elegido el prefijo "&" porque es el invocador de la función en Perl, y porque
al principio es ilegal en Shell.

$ (RAÍZ) / incluir /%. H:% .h
& ln $ (entrada) $ (salida)

noeco
@ Normalmente, cada comando de shell se imprime a medida que se ejecuta. Sin embargo, si la primera palabra
de la acción es "noecho" (o si comienza con el carácter "@"), entonces el comando
no se imprime. Por ejemplo,

% .o:% .cxx
noecho $ (LIBTOOL) --mode = compilar $ (CC) -c $ (entrada)

Esto significa que cuando se ejecuta el comando libtool, no se imprime. (Libtool
en sí mismo generalmente imprime el comando modificado que ejecuta, por lo que es redundante para
imprimirlo dos veces.)

ignorar_error
- Normalmente, si el comando de shell devuelve un estado distinto de cero, makepp aborta porque
el comando falló. Sin embargo, algunos programas configuran incorrectamente el estado al salir o
puede haber un error que realmente no es fatal y no debería abortar todo
Compilacion. Puede hacer que makepp ignore el estado de devolución especificando
"ignore_error" como la primera palabra de la línea de comando (o "-" como el primer carácter).
Por ejemplo,

$ (distribución falsa):
ignore_error rm -r my_program - $ (VERSION) # Deshazte de la basura anterior.
& mkdir my_program - $ (VERSIÓN)
& cp $ (ARCHIVOS) my_program - $ (VERSION)
tar cf my_program - $ (VERSION) .tar my_program - $ (VERSION)

Este comando crea un directorio, copia un montón de archivos en él y luego coloca
todo en un archivo tar para su distribución. Es una buena idea limpiar el
contenido anterior del directorio, si había algo allí anteriormente, y eso es
lo que hace la primera línea. El "rm" puede fallar, pero se ignora su estado de retorno.

perl
maquillaje
Esto es esencialmente lo mismo que la declaración de perl, pero se realiza cada vez que
ejecutando la regla, no al leer el archivo MAKE. La primera variante es simple Perl
código, mientras que la segunda variante pasa primero la declaración a través de la variable de estilo Make
expansión.

Para las dos posibilidades de poner los tirantes del cuerpo, vea la explicación en
"perl_perlcode" en makepp_statements. Tenga en cuenta que la tercera variante explicada allí
no tiene sentido aquí, porque todas las líneas de acción deben estar sangradas. Debes señalar
falla en declaraciones de Perl, llamando "morir".

Por regla, las declaraciones de Perl se evalúan actualmente en un subproceso común, excepto en
Windows. Eso significa que solo tienen acceso de lectura a cualquier variable de archivo MAKE. Tambien es
el proceso que ejecuta acciones que no son de Perl. Entonces, llamar al ejecutivo o salir confundirá
makepp. Pero esto puede cambiar en el futuro. Para una forma eficiente de llamar a Perl
scripts, consulte el elemento anterior "&" o "ejecutar".

$ (versión falsa):
noecho perl {{# $ (objetivo) & $ (VERSIÓN) de Perl:
print "Esto es" .f_target (). "$ VERSION \ n";
}}
echo Puedes mezclar esto con los comandos de Shell
-makeperl {print "Esto es $ (objetivo) $ (VERSIÓN) \ n"}

Hay varios tipos diferentes de reglas, cada una con diferentes propósitos.

Explícito Reglas
destino1 destino2: dependencia1 dependencia2 ...
acciones a realizar

Esta sintaxis especifica que para hacer target1 or target2, todos los archivos
dependencia1, dependencia2, etc., ya debe haberse realizado. Entonces las acciones dadas son
ejecutado por el shell para hacer los objetivos.

La primera regla explícita en un archivo es el destino predeterminado y se hace si no especifica
cualquier destino en la línea de comando.

A diferencia de los programas tradicionales de make, makepp generalmente asume que una invocación de la acción
realiza todos los destinos (a menos que no haya dependencias). Por ejemplo, una invocación
de yacc crea ambos archivos de salida para esta regla:

y.tab.c y.tab.h: analizador.y
$ (YACC) -d parser.y

Tenga en cuenta que otras implementaciones de make no tienen el concepto de un solo comando
producir varios archivos de salida, por lo que cuando especifique varios objetivos,
ejecutar la regla una vez por objetivo. Makepp volverá a este comportamiento si parece
este es un archivo MAKE de estilo antiguo. Específicamente, ejecutará la regla una vez por objetivo,
en lugar de solo una vez en general, si se cumplen todas las siguientes condiciones:

· La acción de la regla menciona la variable automática $ @. (Los sinónimos "$ (salida)" o
"$ (target)" no activa este comportamiento).

· La acción de la regla no menciona la variable automática "$ (salidas)" (o su sinónimo
"$ (objetivos)").

· Esta no es una regla de patrón y no existe una cláusula foreach.

Por ejemplo,

todas las pruebas de instalación:
para subdirectorio en $ (SUBDIRS); hacer cd $$ subdir && $ (MAKE) $ @; CD ..; hecho

es un modismo común en los archivos MAKE y makepp lo admite. (Tenga en cuenta que nunca debe usar
make recursivo en cualquier nuevo archivo MAKE que escriba - use la instrucción "load_makefile", o
carga implícita de archivos MAKE en su lugar).

Si desea que se ejecute la misma regla una vez para cada objetivo (por ejemplo, porque los objetivos
tienen comandos similares), es preferible utilizar una regla de patrón (ver más abajo) o una
cláusula "foreach". Por ejemplo, si con un programa de creación tradicional, escribiría:

a B C D:
hacer_algo para construir $ @> $ @

en makepp, probablemente quieras escribirlo así:

$ (foreach):: foreach abcd
hacer_algo para construir $ (salida)> $ (salida)

Falso tiene como objetivo

A falso dirigidos es un objetivo que nunca existirá en el sistema de archivos; es solamente un
forma de hacer que makepp construya algunos objetivos y posiblemente ejecute algunos comandos adicionales.

Un objetivo falso típico es "todos", que normalmente se utiliza para hacer que todo lo que pueda
construido para ser construido, así:

todos: prog1 prog2 subdir / prog3 subdir2 / libmine.a
@ & echo "¡Todo listo!"

Si escribe "makepp all", o si pone todo como el primer objetivo explícito en su archivo MAKE
(que es típico) y simplemente escriba "makepp", entonces hará que todas las dependencias sean
construido, luego imprimirá "¡Todo listo!". En este punto, makepp buscará el archivo ./todos
y descubrirá que no existe. Se quejará en voz alta.

Para evitar que makepp espere el archivo ./todos para salir, debes decirle que es un
objetivo falso. Simplemente coloque una línea como la siguiente en su archivo MAKE (no hace ninguna diferencia
dónde):

.PHONY: todos

Una alternativa equivalente que a veces es más conveniente es usar el "$ (falso)"
función, así:

$ (falso todo): prog1 prog2 subdir / prog3 subdir2 / libmine.a

Los objetivos falsos en un archivo MAKE pueden hacer referencia a objetivos falsos en otro archivo MAKE. Este es
a menudo se hace con el objetivo "limpio", como este:

# Makefile de nivel superior:
# muchas reglas y cosas aquí
#....
$ (limpieza falsa): subdir1 / clean subdir2 / clean
& rm -fm mi_programa

Luego, en los subdirectorios, los archivos MAKE podrían leerse así:

# Makefile en un subdirectorio
#...
$ (falso limpio):
& rm -fm $ (comodín * .o * .a)

Pero hoy en día usarías el comando "makeppclean", en lugar de un objetivo limpio.

Comodines

Es seguro especificar comodines en la lista de dependencias. Los comodines no solo coinciden con los archivos
que existen, pero archivos que se pueden crear dadas las reglas en el archivo MAKE. Por ejemplo,
para construir una biblioteca a partir de todos los archivos .o en un directorio, puede escribir esto:

libmine.a: * .o
& rm -f $ (salida)
ar cr $ (salida) $ (entradas)

Esto funcionará incluso si ninguno de los archivos ".o" se ha creado todavía, porque makepp's
los comodines coinciden con archivos que aún no existen pero que se pueden crear. Esto incluso mejorará
archivos cuya regla se descubre más tarde (en el mismo archivo MAKE o uno que aún no se ha leído). En esto
último punto, se diferencia de la función "comodín", que se limita a las reglas conocidas,
ya que debe devolver su resultado cuando se expande.

Makepp admite todos los comodines de shell habituales ("*", "?" Y "[]"). También tiene un
comodín "**" que coincide con cualquier número de directorios intermedios. (Esta idea fue robada
de zsh.) Por ejemplo, "** / *. c" coincide con todos los .c archivos en todo el árbol de fuentes.
"objetos / ** / *. o" coincide con todos los .o archivos contenidos en cualquier parte del subdirectorio objetos
o cualquiera de sus subdirectorios o cualquiera de sus subdirectorios. El comodín "**" no
siga enlaces suaves a directorios en cualquier nivel. Tampoco devolverá nunca objetivos falsos.

Los comodines de Makepp ignorarán los archivos o directorios que existen pero que no se pueden leer. Después
todos, estos archivos no se pueden utilizar en el proceso de compilación de todos modos. Poner archivos ilegibles en un
directorio es principalmente útil para inhibir la importación automática del archivo dado desde un
repositorio.

La afirmación inicial fue que esto es seguro. Esto es en el sentido de que funciona si
los archivos ya existen o deben compilarse primero. Sin embargo, no es seguro en el sentido
que aún coincidirá con los archivos que fueron creados por makepp, pero que ya no tienen una regla (p. ej.
quitaste el .c archivo, pero el .o archivo todavía está allí.) Para evitar esto, utilice el
Opción "--rm-stale".

Patrón de Costura reglas
Una regla de patrón es una regla que se aplica en función de algún patrón textual. Esto se usa para
aplique la misma regla a toda una clase de archivos. La sintaxis es la misma que la de GNU make
reglas de patrón:

% .o:% .c
$ (CC) -c $ (entrada) -o $ (salida)

Esto dice que cualquier archivo en el directorio actual que coincida con "* .c" se puede convertir en
el archivo .o correspondiente usando el comando dado.

Tenga en cuenta que se pueden proporcionar varias dependencias de patrones. Por ejemplo, si tu xyz.o presentar
depende de la correspondiente xyz.cpp archivo, y también en un archivo llamado moc_xyz.cflags que
contiene las opciones del compilador, esto podría expresarse con:

% .o:% .cpp% .cflags
$ (CXX) `cat $ (raíz) .cflags` -c $ (entradas) -o $ (salida)

También puede tener varios patrones de destino. Por ejemplo,

% .tab.h% .tab.c:% .y
yacc -d $ (entrada)
& mv y.tab.h $ (raíz) .tab.h
& mv y.tab.c $ (raíz) .tab.c

Normalmente, las reglas de patrones solo buscan archivos en los directorios actuales. Puedes forzar
que busquen en el directorio actual y en todos los directorios debajo de él configurando

makepp_percent_subdirs: = 1

antes de la primera regla de patrón en su archivo MAKE o en la línea de comando, por ejemplo.

Existe una clara diferencia entre "%" y el comodín "*", aunque ambos coinciden
cadena: el comodín devuelve una lista de archivos que se utiliza por completo en ese momento. Entonces
esto depende de todos .o archivos compilables aquí:

prog: * .o
$ (LD) $ (LDFLAGS) $ (entradas) -o $ (salida)

Esto no se pudo lograr reemplazando "*" con "%", porque este último es para uno por uno
emparejamiento de entrada a salida, produciendo internamente una regla para cada tallo emparejado.

Estático patrón reglas
Una regla de patrón estática es una regla de patrón que se aplica solo a un conjunto limitado de archivos:

$ (MÓDULOS_ESPECIALES) .o:% .o:% .cpp
$ (CXX) -c $ (entrada) -o $ (salida)

Esto dice que la regla del patrón se aplica solo a los archivos en "$ (SPECIAL_MODULES) .o".

Esto es principalmente por compatibilidad con la marca GNU; Cada una de las reglas (ver más abajo) es más
poderosa forma de hacer lo mismo.

Para cada reglas
La sintaxis de la regla de patrón anterior es lo suficientemente potente como para admitir casi todas las compilaciones, pero
de vez en cuando es necesario hacer algo más complicado. Makepp ofrece más
sintaxis potente: la cláusula ": foreach" de la regla.

target_expression: dependency_expression: foreach lista de archivos
acciones

El tipo más simple de regla para cada uno es simplemente una regla de patrón cuya aplicación está restringida
a una lista específica de archivos. Por ejemplo, suponga que tiene una regla de patrón que dice
makepp cómo compilar todo .c archivos. Sin embargo, tienes una lista de .c archivos para los que usted
Quieres hacer algo diferente. Podrías hacer algo como esto:

# Aquí está la regla que se aplica a todo:
% .o:% .c
$ (CC) $ (CFLAGS) -c $ (entrada) -o $ (salida)

% .o:% .c: foreach $ (SPECIAL_MODULES)
$ (CC) $ (SPECIAL_CFLAGS) -c $ (entrada) -o $ (salida)

Un uso aún más poderoso de las reglas foreach aprovecha el hecho de que la variable
"$ (foreach)" se establece a su vez para cada archivo que coincida con la lista de archivos y el destino y
Se evalúan las expresiones de dependencia. La lista de archivos puede contener comodines, y estos
coincidir incluso con archivos que aún no existen pero que se pueden crear (consulte "Comodines" en
makepp_rules).

Esta es una sintaxis difícil de manejar pero extremadamente flexible, porque la variable "$ (foreach)"
puede aparecer de cualquier forma en la expresión. Primero, tenga en cuenta que las reglas de patrones son de hecho una
caso especial de reglas foreach; la regla del patrón

% .o:% .c
$ (CC) $ (CFLAGS) -c $ (entrada) -o $ (salida)

es exactamente equivalente a:

$ (patsubst% .c,% .o, $ (foreach)): $ (foreach): foreach * .c
$ (CC) $ (CFLAGS) -c $ (entrada) -o $ (salida)

(De hecho, se convierte en aproximadamente eso internamente).

Como ejemplo de cómo usaría una cláusula ": foreach" donde una regla de patrón no es
suficiente, suponga que tiene algo .c archivos que se crean utilizando algún tipo de preprocesador
que toma como archivos de entrada con un .k extensión. Quieres compilar esos .c archivos con un
diferente conjunto de opciones de compilación que el habitual .c archivos que son fuente ordinaria
archivos. Podrías hacer algo como esto:

# Regla para archivos .c ordinarios:
% .o:% .c
$ (CC) $ (CFLAGS) -c $ (entrada) -o $ (salida)

# Regla para crear archivos .c a partir de archivos .k:
% .c:% .k
$ (preprocesador) $ (entrada)> $ (salida)

# Reglas de construcción especiales para archivos .c que se crean a partir de archivos .k:
$ (foreach:%. k =%. o): $ (foreach:%. c =%. k): foreach * .k
$ (CC) $ (SPECIAL_CFLAGS) -c $ (entrada) -o $ (salida)

(Esto usa la sintaxis de referencia de sustitución un poco más concisa en lugar de llamar
"patsubst" explícitamente).

Tenga en cuenta que si todo lo que quiere hacer es cambiar el valor de una variable ("CFLAGS" en este
caso) a veces es más conveniente utilizar variables específicas de destino.

Legado sufijo reglas
Para compatibilidad con versiones anteriores, makepp admite las reglas de sufijos de estilo antiguo.

.sufijo1.sufijo2:
acciones

es equivalente a

% .suffix2:% .suffix1
acciones

pero mucho más difícil de recordar. (¿Qué sufijo viene primero?) Normalmente, aparecerá una regla
en un archivo MAKE heredado como este:

.co:
$ (CC) $ (CFLAGS) -c $ *. C -o $ *. O

que es exactamente equivalente a

% .o:% .c
$ (CC) $ (CFLAGS) -c $ (entrada) -o $ (salida)

Contradictorio reglas
Cuando hay más de una forma de crear un archivo, makepp usa un procedimiento simple para
determinar qué regla utilizar.

· Es un error tener reglas explícitas en conflicto para crear un archivo.

· Las reglas de patrón y las reglas foreach con comodines nunca anulan las reglas explícitas. Por lo tanto
Se pueden usar reglas explícitas para especificar excepciones para reglas de patrón. (Tenga en cuenta que simplemente
el uso de una cláusula ": foreach" no convierte algo en una regla de patrón. Debe tener un
comodín (como "*" o "?") como parte del nombre de archivo en la cláusula ": foreach". Si esto es
sólo una lista explícita de archivos, se trata como una regla explícita para cada uno de esos
archivos.)

· Cuando las reglas de patrones en conflicto provienen de diferentes archivos MAKE, las reglas de "más cercano"
Los archivos MAKE anulan las reglas de los archivos MAKE "más lejanos". "Más cerca" significa que el archivo MAKE
se encuentra más cerca del destino en la jerarquía de directorios (es decir, el nombre de archivo del
el destino relativo al directorio desde el que se ejecuta el archivo MAKE es más corto). Si esto
no distingue los archivos MAKE, entonces la regla del archivo MAKE que se carga
se utiliza el último.

Esto significa que puede especificar una regla de patrón que se aplique a todos los archivos de su
árbol de directorios completo en solo el archivo MAKE de nivel superior, pero luego puede anularlo en
un archivo MAKE de nivel inferior. Por ejemplo, su archivo MAKE de nivel superior podría contener:

% .o:% .c: foreach ** / *. c
$ (CC) $ (CFLAGS) -c $ (entrada) -o $ (salida)

y podría tener un archivo MAKE en uno de los subdirectorios que dice:

% .o:% .c
$ (CC) $ (SPECIAL_CFLAGS) -c $ (entrada) -o $ (salida)

· Se prefieren las reglas de patrones que tienen una cadena de inferencia más corta sobre otros patrones
normas. Por ejemplo, si tuviera las siguientes reglas (basadas en un ejemplo del
Kernel de Linux):

% .s:% .c
$ (CC) -s $ (entrada) -o $ (salida)

% .o:% .s
$ (AS) $ (entrada) -o $ (salida)

% .o:% .c
$ (CC) -c $ (entrada) -o $ (salida)

Si necesitamos compilar "xyz.o", podríamos compilar el archivo ".s" intermedio y luego
ejecutar eso a través del ensamblador usando las dos primeras reglas, o podríamos ir directamente a un
Archivo ".o" utilizando la última regla. Se prefiere la última regla porque hay menos
pasos en la cadena de inferencia (uno en lugar de dos).

· Las reglas de patrón posteriores en un archivo MAKE anulan las reglas de patrón anteriores. (Este es
al revés de GNU make.) Esto significa que debe poner sus reglas más generales
antes, y sus reglas más específicas más adelante. Por ejemplo,

% .o:% .c # Regla general de compilación.
DE ACTUAR!

especial _%. o: especial _%. c # Regla especial para archivos con
acción diferente # prefijo "especial_".

Regla opciones
A veces es necesario proporcionar opciones adicionales para modificar la forma en que makepp ejecuta el
regla. Estas opciones se especifican como ": optionname value", ya sea en la línea que contiene
las dependencias, o en la siguiente línea.

Proporcionar las opciones en líneas separadas puede hacer posible que utilice el mismo
makefile con makepp y una marca tradicional. Por ejemplo,

objetivo: dependencias
: firma target_newer
acciones

funcionará bien con una marca Unix tradicional, porque interpreta la línea ": firma"
como un comando de shell, y un comando que comienza con dos puntos no hace nada.

: build_cache / ruta / a / compilación / caché
objetivo: dependencias
: build_cache / put / cache / files / over / there
acciones

Especifica la ruta a una memoria caché de compilación que se utilizará para los archivos producidos por esta regla. Esta
anula el efecto de la instrucción "build_cache" o el comando "--build-cache"
opción de línea, si existe, para esta regla. Consulte makepp_build_cache para obtener detalles sobre la compilación.
cachés.

Si especifica "ninguno" en lugar de una ruta, inhabilita la caché de compilación para este
regla particular. Esto puede resultar útil para evitar desperdiciar espacio en disco en archivos que
saber que no son útiles para almacenar en caché, ya sea porque está muy seguro de que nunca lo serán
reutilizados o porque están construidos tan rápido que no vale la pena almacenarlos en caché.

: build_check método_comprobación_construcción
objetivo: dependencias
: build_check target_newer
acciones

Esto le dice a makepp qué algoritmo usar para decidir si los objetivos necesitan ser reconstruidos.
Consulte makepp_build_check para obtener más detalles. Esto anula el efecto de la
instrucción "build_check" o la opción de línea de comando "--build-check-method", si existe, para
Esta regla.

: env VARIABLE ...
Agregue una dependencia de los valores de las variables de entorno nombradas. Si alguno de ellos
difieren de la compilación anterior, entonces los objetivos se consideran obsoletos, si el
El método build_check así lo dicta. (Todos los métodos de verificación de compilación incorporados, excepto
target_newer respeta esto.)

VARIABLE puede tener el formato "nombre de archivo en PATH_VARIABLE" (entre comillas), en cuyo caso el
Los destinos se consideran obsoletos si el primer directorio delimitado por dos puntos
El valor de PATH_VARIABLE en el que existe el nombre de archivo es diferente al de la última compilación.
Esto se puede usar para evitar reconstruir los objetivos cuando PATH_VARIABLE cambia en un
manera irrelevante.

:envío comando ...
Incluya cada acción de shell (pero no las acciones de Perl ni los comandos de Perl) en un "sh -c '...'"
y anteponerle comando, pero suponga que el objetivo no depende del comando.
Esto es útil si desea enviar acciones a un sistema de cola de trabajos, pero el resultado es
se supone que es independiente de los parámetros de la cola, así como de si la cola
el sistema se utiliza en absoluto.

:incluir archivo_o_patrón
La regla varía según el compilador:

% .o:% .c
: incluye% .d: firma C
gcc-MD-c...

% .o:% .c
: incluye% .u: firma C # IBM usa un sufijo diferente
xlc-M-c...

sub dependify {# Convierte la charla de Microsoft en un formato útil
s / \ $ / \ $ \ $ / g;
s / (Nota: incluido el archivo: *)? (. +?) \ r? \ n / $ 1? "'$ 2'": "'" .f_output (). "':" / E;
}
% .o:% .c
: incluye% .d: firma C
cl -showIncluye -c ...> $ (raíz) .d
& sed & depender -o + <$ (raíz) .d

Algunos compiladores (el icc de Intel como el gcc anterior o el xlc de IBM) pueden producir dependencia
archivos sobre la marcha. Es decir, mientras compilan, escriben un archivo MAKE que makepp puede
incluir. La ventaja sobre el escáner de makepp es que está garantizado al 100%
correcto, donde solo podemos acercarnos.

Esta opción aprovecha eso de una manera especial: si el archivo no está presente, es decir
normalmente en la 1ª compilación, se produce un escaneado normal. Pero si el archivo está presente, no
se produce el escaneo (por lo que especificamos una firma inteligente arriba, no el escaneo cae
volviendo al tonto predeterminado de marca de tiempo y tamaño). En su lugar, incluye el archivo, antes
ejecutando la regla. Después de ejecutar con éxito la regla, olvida lo que sea que
leído por primera vez, dado que el archivo podría estar desactualizado. En su lugar, lee
el archivo nuevamente, si cambió, por tener información de compilación actualizada.

ADVERTENCIA: Esto es inherentemente poco confiable. El archivo de dependencia es producido por el mismo
regla para la que es una dependencia. Por otro lado, el compilador conoce todo
son subincluidos internos, que makepp generalmente ignora. Esta es una confiabilidad
ventaja solo para el caso en el que un parche del compilador corrige solo las subincluidos. los
El precio es que makepp termina viendo muchos más archivos, lo que lleva tiempo.

Hay un problema cuando quita una declaración "#include" y el archivo correspondiente:
Todavía se mencionará en el archivo de dependencia desde la última vez, cuando se
necesario. En tal caso, debe editar el archivo de dependencia para eliminar la dependencia
que ya no se puede cumplir.

Esta función no se puede utilizar con un caché de compilación porque se obtiene un archivo desde allí
requiere saber todo sobre el archivo. Pero un archivo de dependencia depende de esos
archivos sobre los que makepp aprende al leerlos. Esta dependencia circular normalmente no es
posible en un sistema de construcción confiable. Esta es una excepción porque después de reconstruir
y releyendo un archivo de dependencia, todo es correcto nuevamente.

Si crea en sus repositorios, makepp recogerá el archivo de dependencia del
1er repositorio que contiene uno. Esto es diferente a otros archivos, donde toma el primer
con la firma esperada. Esto es mejor que para compilar cachés, donde por falta de
firma, ni siquiera puede encontrar el archivo.

:última oportunidad
Habilite una regla abierta, como

% .foo foo% .bar:: last_chance
& echo $ @ -o $ @
& cp $ (salidas)

Debido a que una regla como esta podría generar un número esencialmente infinito de objetivos,
un objetivo de esta regla no coincidirá con una función $ (comodín) o una regla de patrón a menos que
algo más ya ha creado una instancia de la regla haciendo referencia al objetivo específicamente.
Además, si se especifica "--rm-stale", entonces un objetivo sobrante de un
makepp run aparecerá obsoleto si la única forma de construirlo es a través de una regla last_chance
que aún no ha sido instanciado para el objetivo, lo cual es un comportamiento deseable porque
la compilación fallará de manera más consistente cuando se basa erróneamente en un comodín para
coincidir con los objetivos de una ejecución anterior.

La opción ": last_chance" tiene como objetivo llamar la atención sobre el comportamiento especial del
regla con respecto a la coincidencia de comodines.

: analizador analizador
Esto le dice a makepp cómo analizar el comando para detectar (incluir) archivos. Generalmente,
makepp adivina cómo hacer esto basándose en las palabras del comando en sí (ver
makepp_scanning para obtener más detalles). Sin embargo, si makepp adivina incorrectamente, es posible que desee
indique explícitamente el analizador, así:

% .o:% .abc
: analizador c_compilation
acción aquí

Esto hace que makepp realice el mismo análisis y escaneo que para C / C ++
construir comandos, incluso si no reconoce la acción como una compilación de C.

El analizador predeterminado depende del comando. Si no especifica una opción ": analizador",
luego se examina la primera palabra de cada comando. Por ejemplo para una compilación o enlace
comando, makepp usará el analizador "c_compilation"; o si el comando se parece al
Variante GNU, "gcc_compilation". Si no se encuentra ningún analizador, utiliza el analizador "ninguno". Para
más detalles sobre esto, o si desea escribir su propio analizador o cambiar makepp's
analizadores predeterminados, consulte makepp_scanning.

Tenga en cuenta que esto se aplica a todos los comandos de la regla, que puede que no sea lo que desea:

% .o:% .c: compilación c del analizador
@echo 'Construyendo $ (salida)'
@funny_cc...

Esto también interpretará "echo" como un compilador y deducirá su argumento 'Building
mymodule.o 'como una dependencia implícita. Esto dará lugar a la denuncia de que
no sabe cómo crear un archivo de este tipo. En este caso, estaría mejor con
"analizador_registro". Allí encuentras una explicación de cómo analizador se puede dar como
classname o como nombre de función.

:firma método_de_firma
objetivo: dependencias
: firma md5
acciones

Esto le dice a makepp qué algoritmo usar para determinar si las dependencias han cambiado.
Consulte makepp_signatures para obtener más detalles. Los métodos de firma que se incluyen con el
La distribución de makepp son "simple", "md5", "C" o "c_compilation_md5", y
"objeto_compartido". Esto anula cualquier método de firma especificado con "-m" o
Opciones de línea de comando "--signature-method", o con la instrucción "signature".

Especiales personajes
Makepp puede admitir nombres de archivo que tengan caracteres especiales como dos puntos o un espacio.
Suponga, por ejemplo, que desea crear un archivo llamado "a: cosa" a partir del archivo "b: cosa".
No puedes escribir la regla de esta manera:

a: cosa: b: cosa # Esto es un error de sintaxis
& cat $ (entrada) -o $ (salida)

porque makepp no ​​sabrá qué dos puntos separan los objetivos de las dependencias y cuáles son
parte de los nombres de archivo. En su lugar, simplemente encierre el nombre entre comillas, así:

"a: cosa": "b: cosa"
& cat $ (entrada) -o $ (salida)

Ahora la regla es inequívoca.

La sintaxis de citas de Makepp es bastante similar a la del shell. Puede, por ejemplo, utilizar single
comillas en lugar de comillas dobles, o puede escapar de los caracteres especiales con una barra invertida:

una \: cosa: 'b: cosa'
& cat $ (entrada) -o $ (salida)

Supongamos, por ejemplo, que su nombre de archivo es "'"!; \ $ ". Ahora, ¿por qué querría un nombre de archivo así?
No lo sé, pero aquí hay varias formas de especificarlo para makepp (y el shell):

\ '' "!; \ $$ '
"'\"!; \\ $$ "

Preste atención a cuándo makepp elimina las comillas y cuándo lo hace el shell. Makepp mira
citas solo en los siguientes casos:

· En la familia de pruebas "ifeq"

· Antes y después de los dos puntos de la regla

· En un comando integrado de makepp

· En una función que pertenece a archivos

A diferencia del shell, makepp no ​​expande las comillas mientras las asigna a una variable. Por lo tanto
las siguientes reglas son idénticas:

ARCHIVO = 'nombre con espacios'
x: = $ (print $ (FILE)) # solo para comprobar que las comillas siguen ahí
$ (ARCHIVO): # comillas alrededor de un solo archivo eliminado por makepp
& echo hola -o $ (ARCHIVO) # comillas alrededor de un solo archivo eliminado por makepp
echo allí >> $ (FILE) # comillas alrededor de un solo archivo eliminado por Shell
'nombre con espacios':
& echo hola -o'nombre con espacios '
echo allí >> '$ (salida)' # comillas fueron eliminadas arriba, agréguelas de nuevo

Tenga en cuenta que (a diferencia del Shell) las variables que comienzan con "$" se expanden incluso dentro de un solo
citas. Los signos de dólar no se pueden proteger con comillas o barras diagonales inversas. Para obtener un literal
signo de dólar, use un signo de dólar doble, por ejemplo,

$ (falso todo):
@ & echo Este es un signo de dólar: $$
@for val en abcd; echo $$ val; hecho

Generalmente, debería poder tratar con casi cualquier carácter especial citandolo
de alguna manera. Esto incluye espacios, caracteres de control, etc. Sin embargo, tenga en cuenta que en
presente, la eliminación de comentarios de makepp es algo simplista y cualquier carácter "#"
precedidos de un espacio en blanco se interpretarán como comentarios, independientemente de cómo se citen.

Cuando se coloca un nombre de destino o dependencia en una variable automática como "$ (salida)",
las comillas y las barras invertidas se eliminan. Esto significa que si desea hacer referencia al
filename en las acciones, probablemente tendrá que citarlo nuevamente, así:

"un nombre de archivo con espacios":
echo "Contenidos especiales"> "$ @"

Si no pone las comillas alrededor de $ @, el shell verá el comando

echo "Contenido especial"> un nombre de archivo con espacios

que escribe la cadena "Nombre de archivo de contenido especial con espacios" en el archivo llamado a.
Probablemente esto no sea lo que quieres.

Use makepp_rules en línea usando los servicios de onworks.net