makepp_scanning: en línea en la nube

PROGRAMA:

NOMBRE

makepp_scanning: cómo los hallazgos de makepp incluyen archivos y otras dependencias ocultas

DESCRIPCIÓN

Makepp puede determinar dependencias u objetivos adicionales para ciertos comandos que conoce
algo sobre. Esto es especialmente importante para la compilación de C / C ++, donde también es
propenso a errores para enumerar manualmente todos los archivos de inclusión de los que depende un archivo de origen determinado.
Al observar el comando de compilación y los propios archivos fuente, makepp es capaz de
Determine con precisión qué archivos de objeto deben reconstruirse cuando algunos incluyen cambios de archivo.

Ejemplo: dada una regla

foo.o: # Normalmente% .o:% .c, solo como ilustración
tiempo -p / bin / libtool -bar / usr / bin / cc -c -I en algún lugar foo.c

makepp sabe que "time" y "libtool" deben omitirse y que "cc" es el comando real
para ser analizado aquí. Entiende que foo.c es el archivo de entrada y, por lo tanto, una dependencia de
Esta regla. Además, escaneará ese archivo en busca de declaraciones de inclusión, también en
directorio en alguna parte, porque entendió las opciones del comando.

En realidad, hay tres pasos para lo que históricamente se conoce como escaneo:

1. La acción de la regla se divide en líneas (las líneas de continuación cuentan como una). Cada línea
(excepto incorporados y bloques Perl) es léxicamente analizo como uno o más comandos de Shell.
Las redirecciones se reconocen como entradas o salidas de esta regla. La primera palabra de cada uno
El comando se busca (con su parte de directorio pero, si no se encuentra, nuevamente sin él) para
busque un analizador para ello. Estas se convierten en dependencias opcionales, se construyen si es posible,
pero se ignora si no se encuentra, ya que makepp no ​​puede saber qué parte de un comando complejo es
realmente correr.

Los comandos entre comillas inversas se analizan pero no se ejecutan. (A menudo la ejecución es importante,
pero esto sería una gran interferencia de makepp.) Es mejor estilo evitarlos.
En su lugar, haga que makepp ejecute el comando como máximo una vez asignándolo de esta manera especial:

XYZFLAGS; = $ (shell pkg-config --cflags xyz)

Actualmente solo hay una clase lexer, que comprende Bourne Shell. Para mejorar
manejar C Shell o "command.com", se pueden crear subclases. Sin embargo, gran parte de la sintaxis es
lo suficientemente similar como para no justificar esto. Ponte en contacto si quieres contribuir.

2. Para comandos conocidos, el correspondiente comando analizador (también conocido como analizador)
analiza las opciones y argumentos importantes. Los disponibles se describen a continuación.

Incluso si no se encontró un analizador especializado, el genérico hace que el comando sea ejecutable
una entrada de esta regla. Puedes cambiar eso con --no-path-ejecutable-dependencies
opción de comando.

3. Si el analizador reconoce algún archivo de entrada, se envía al escáner elegido por el
analizador. Encuentra más entradas buscando "#include" o declaraciones comparables.

Este es el paso más caro. Todos los resultados se almacenan en caché para evitar que se repita
innecesariamente.

Si makepp cree que está compilando una fuente C / C ++ pero no puede encontrar un analizador, dará una
mensaje de advertencia para hacerle saber. Esto generalmente significa que enterró el comando del compilador
demasiado profundamente en la acción para que makepp la encuentre. Por ejemplo, he visto reglas como esta:

% .o:% .c
@echo Compilando $ <ahora; envoltura_oscuridad gcc -c $ <$ (CFLAGS) -o $ @

Las primeras palabras de las acciones aquí son "echo" y "obscure_wrapper", para las cuales hay
no hay analizadores, por lo que makepp no ​​buscará archivos incluidos en este caso. Puedes ignorar el
comando prefijado por:

registro-analizador dark_wrapper saltar-palabra

Las siguientes secciones documentan los analizadores y escáneres integrados. En el nombre puedes
utilice "-" indistintamente con "_".

ESCÁNERES (ANALIZADORES)

Los distintos escáneres deben ser elegidos por un analizador de comandos, que se da entre paréntesis:

C / C ++ compilación (c-compilación, compilación gcc)
El escáner C / C ++, maneja ambos lenguajes indistintamente. De hecho, solo mira
instrucciones del preprocesador, por lo que se puede utilizar para bastantes idiomas. El analizador que
activa tiene una variante especial para las muchas opciones de gcc, que se elige si el
El nombre del comando incluye la cadena "gcc" o g ++. Si compiladores para otros lenguajes con C
el preprocesador usa las mismas opciones que el compilador de C (al menos "-I"), entonces este analizador funciona
multa.

Examina el comando para las opciones "-Idir" que especifican la ruta de inclusión o las opciones "-Ldir"
especificando la ruta del enlace. A continuación, analiza los archivos de origen en busca de directivas "#include" y
también mira la línea de comando para ver si se mencionan archivos de origen o bibliotecas
que no se enumeran como dependencias. Los reconoce por su extensión.

Este analizador muestra un mensaje de advertencia si los archivos incluidos con "#include" file.h "" no están
encontrado, o no compilable por makepp, en la ruta de inclusión, o en el directorio que contiene el
archivo que es "#includ" ing, o en / usr / include. No se da ninguna advertencia si se incluye un archivo
con "#include "no se encuentra. Makepp asume que está en algunos sistemas incluyen
directorio que el compilador conoce, y que los archivos en el sistema incluyen directorios
no cambiará.

Además, los archivos en / usr / include, / usr / local / include, / usr / X11R6 / includey cualquier otro
Los directorios que no se pueden escribir no se analizan para ver qué incluyen. Makepp asume
que estos archivos no cambiarán. (Si se está ejecutando como root, la prueba de capacidad de escritura es
realizado con el UID y GID del directorio desde el que ejecutó makepp. Esto es tan recopilatorio
un programa como un usuario normal y luego hacer "makepp install" como root no causará extra
directorios a escanear.)

Este es un escáner bastante simple. Se confundirá si haces cosas como esta:

#ifdef INCLUYE_ESTO
#include "this.h"
#terminara si

porque no conoce los condicionales del preprocesador. Suele ser inofensivo; eso
puede causar que archivos adicionales adicionales se etiqueten como dependencias (ocasionalmente causando
reconstrucciones innecesarias), o podría hacer que makepp advierta que el archivo de inclusión no fue
fundar. Puede ignorar los mensajes de advertencia o colocar un archivo vacío "this.h"
allí para cerrar makepp.

Si su compilador tiene un nombre divertido, puede decir cualquiera de

register-parser obscure_c_compiler c-compilación
register-parser obscure_gcc_alias gcc-compilación

Embedded SQL C / C ++ compilación (compilación esql)
Estos comandos, que vienen con las distintas bases de datos, preprocesan secciones especiales en
de lo contrario, fuentes similares a C / C ++ y producen encabezados y fuentes C / C ++. Esto encuentra EXEC SQL
INCLUDE las directivas "nombre de archivo" o $ INCLUDE "nombre de archivo".

Se reconocen estos preprocesadores: Altibase APRE * C / C ++ (abre), CASEMaker DBMaker
(dmppcc), Firebird/InterBase (gpre), IBM DB2 (db2 precompilar db2 prep) E Informix
ESQL / C (esql), Ingres (esqlc), mimo (esql), Oráculo (Proc), PostgreSQL (ecpg) & YARDA
(yarda). Si no se reconoce su preprocesador, puede decir

registro-analizador dark_esqlc_preprocessor esql-compilation

Sin embargo, esto solo manejará el estilo común a Informix y otros: Argumentos de comando
que terminan en ".ec" son los archivos que se van a escanear, "-I" define la ruta de inclusión y EXEC SQL
Las directivas INCLUDE sin un sufijo se añaden ".h".

Trago (trago)
Swig (Generador de interfaz y envoltorio simplificado, http://www.swig.org/) es un programa que
convierte un archivo de encabezado C / C ++ en las funciones contenedoras necesarias para hacer que su código se pueda llamar
de una variedad de otros lenguajes, como Perl, Python, Tcl, C #, Ruby, OCaml y
probablemente algunos otros que no conozco.

Makepp comprende y analiza la línea de comando swig, buscando las opciones "-I" y "-l".
También sabe cómo escanear los archivos de definición de la interfaz de swig (.i archivos) buscando
% include,% import y también "#include" si "-includeall" está en vigor.

Si tu trago tiene un nombre divertido, puedes decir

register-parser obscure_swig_alias trago

Vera y Verilog (compilación_vcs)
Si diseña hardware, esto le resultará útil.

ignorable envolvedoras (palabra de salto, cáscara)
Makepp reconoce las siguientes palabras de comando y muchas más y las omite
apropiadamente en su búsqueda del escáner correcto: "condor_compile", "distcc",
"ignore_error", "libtool", "noecho" "purificar".

Hay una variante de esto que encuentra los comandos anidados en "sh -c 'command1;
comando2 '".

Si tiene más comandos de este tipo, puede decir

comando register-parser skip-word

libtool

Libtool es un sistema de compilación muy inteligente que simplifica enormemente la creación de
bibliotecas ocultando todos los detalles dependientes del sistema en un script de shell. El único
La dificultad es que los archivos binarios de la biblioteca no se almacenan realmente en el mismo directorio.
como el archivo de salida - libtool en realidad crea un subdirectorio, ".libs", que contiene el
archivos reales. Por lo general, esto no es un problema, pero makepp tiene que saber dónde está el
los binarios son para vincularlos desde un repositorio. Por el momento, las bibliotecas libtool
(archivos ".la") no están vinculados desde repositorios; siempre se reconstruyen si es necesario.
Además, makepp en este momento no puede usar la información de dependencia que está almacenada
dentro del propio archivo ".la". Es de esperar que esto cambie pronto.

Suprimiendo las escanear (Ninguno)
A veces, es posible que no desee analizar una regla o un comando determinado. Puedes apagar
analizar y, por lo tanto, escanear con

register-parser cc ninguno

RELACIONADOS CAMPUS

Análisis rápido y escaneo inteligente
Las opciones de las reglas ": quickscan" y ": smartscan", si corresponde, afectan la forma en que los archivos
son escaneados.

En el modo ": quickscan" (el predeterminado), todas las directivas de inclusión se suponen activas. Esto permite
para un escaneo muy eficiente.

En el modo ": smartscan", se intenta interpretar macros y expresiones para que
las directivas de inclusión inactivas se ignoran. Por ejemplo, el ejecutable producido por
compilar el siguiente programa en C debe no depender de foo.h:

#si 0
#include "foo.h"
#terminara si
int main () {retorno 0; }

PERSONALIZADO ESCÁNERES

Puede especificar su propio analizador en una opción de regla como ": analizador foo" o utilizando
las declaraciones "register_parser" o "register_command_parser".

De cualquier manera, como se describe en "register_parser", allí debe directa o indirectamente
(a través de una clase) especifica una función que crea un objeto analizador. Este objeto normalmente
crear un objeto de escáner para archivos y alimentarlo con sus hallazgos desde la línea de comando
opciones. Estos dos objetos llamarán a los métodos "agregar _ * _ dependencia" del analizador que
reenviar la información al algo más complicado "Mpp :: Lexer :: add _ * _ dependency"
funciones de utilidad.

Sin embargo, su función de analizador también puede hacer este trabajo por sí misma para casos simples. Hay un
par de valores de retorno especiales si esta función no devuelve un objeto analizador:

"indef"
La información del análisis no se puede almacenar en caché y se debe volver a calcular la próxima vez que el objetivo de la regla
necesita ser construido.

"p_none, p_skip_word" o "p_shell"
Estas son de hecho constantes numéricas, que le dicen al lexer que haga el trabajo de estas
pseudo-analizadores.

cualquier referencia, por ejemplo, "\ 1"
Esto es equivalente a devolver un objeto analizador de la base "Mpp :: CommandParser"
class, que solo hará que el comando ejecutable en sí mismo sea una dependencia.

En la mayoría de los casos, los objetos de tipo "Mpp :: CommandParser" deben instanciar al menos un objeto
del tipo "Mpp :: Scanner". La clase base "Mpp :: Scanner" se encarga de la distinción
entre quickscan y smartscan. Tenga en cuenta que el comportamiento de "Mpp :: Scanner" puede ser notablemente
afectados por esta distinción, pero eso debería ser transparente para la clase derivada si es
bien formado. Las nuevas clases "Mpp :: Scanner" derivadas deben probarse en ambos modos.

Si escribe su propia clase "Mpp :: Scanner", también debe basar su decisión de volver a escanear
en la información de construcción "RESCAN". Esto se establece mediante "makeppreplay" después de firmar archivos sin
exploración. Entonces, a pesar de que las firmas sean consistentes, aún es necesario volver a escanear. Si
su "Mpp :: Scanner" usa el método heredado "scan_file1", probablemente esté bien.

Para obtener más detalles, consulte la documentación de la clase respectiva. Para ver ejemplos, consulte
"Mpp :: CommandParser :: Gcc" y "Mpp :: CommandParser :: Vcs". Mira las funciones "p_" en
Mpp / Subs.pm que obtienen alias en sus respectivas clases como "fábrica" ​​cuando se cargan.

Almacenamiento en caché escáner info
Si todos los efectos secundarios importantes del escáner se efectúan a través de llamadas a métodos
de la clase base "Mpp :: CommandParser", esos efectos secundarios se pueden almacenar en caché en la compilación
info, para que puedan reproducirse mediante una invocación posterior de makepp sin
haciendo todo el costoso trabajo de escaneo. Esto puede ahorrar bastante tiempo, especialmente en
modo smartscan.

Si el escáner tiene otros efectos secundarios importantes, entonces debería llamar al objeto "Regla"
método mark_scaninfo_uncacheable. De lo contrario, la información del escáner recuperada de la compilación
La información puede ser inexacta, lo que hace que el resultado de la compilación sea posiblemente incorrecto. Este método es
se llama automáticamente cuando un valor del% de hash del analizador no devuelve un objeto de tipo
"Mpp :: CommandParser", o cuando el analizador se especifica con una opción de regla y el "p_ *"
La rutina no devuelve un objeto de tipo "Mpp :: CommandParser".

La información de escaneo en caché se invalida usando criterios similares a los usados ​​para determinar cuándo
el objetivo está desactualizado. Del mismo modo, se puede recuperar de un repositorio utilizando
Criterios similares a los utilizados para determinar cuándo un objetivo puede vincularse desde un
repositorio.

Puede forzar a makepp a ignorar la información del escáner en caché con la opción "--force-rescan".
Esto es útil cuando un escáner averiado puede haber provocado que se almacenara en caché información incorrecta del escáner.

Ad hoch Escáners
A menudo, tendrá solo uno o pocos archivos que contienen información de dependencia. Tu no
desea escribir esto en un archivo MAKE de forma redundante (ya que la redundancia más tarde a menudo conduce a
inconsistencias cuando se olvida una actualización). Pero tampoco quieres escribir un
Mpp :: Escáner? Como solución alternativa, puede generar un archivo de inclusión sobre la marcha. Por ejemplo
Qt tiene .qrc archivos que pueden verse como:



a B C
xyz
...

Si se adhiere al diseño anterior, puede transformar las líneas relevantes en un makepp
incluir archivo, que se crea automáticamente al ser incluido.

% .qrc.makepp:% .qrc
& grep 's! \ n! $ (raíz) .cc :! || ¡s! * ! ! && ¡s! \¡¡norte!!' $ (entrada) -o $ (salida)

include $ (comodín * .qrc) # .makepp se agrega automáticamente

En el libro de cocina se dan varias variantes de esto. El inconveniente es que comienzas
construyendo mientras lee el archivo MAKE. Entonces la opción de comando --loop no será tan útil
en la primera iteración.

Utilice makepp_scanning en línea mediante los servicios de onworks.net