Este es el comando makepp_build_check que se puede ejecutar en el proveedor de alojamiento gratuito de OnWorks utilizando una de nuestras múltiples estaciones de trabajo en línea gratuitas, como Ubuntu Online, Fedora Online, emulador en línea de Windows o emulador en línea de MAC OS.
PROGRAMA:
NOMBRE
makepp_build_check - Cómo decide makepp reconstruir archivos
DESCRIPCIÓN
A: "arquitectura_independiente", E: "coincidencia exacta", I: "ignore_action", O: "only_action",
T: "target_newer"
Makepp almacena una variedad de información sobre cómo se construyó un archivo dado la última vez.
Esta información incluye el comando de compilación, la arquitectura y las firmas de todos
las dependencias del archivo. (Toda la información almacenada está en el subdirectorio .makepp of
cada directorio.) Si alguna de esta información ha cambiado, makepp generalmente decide
reconstruir el archivo. El método de verificación de compilación es lo que controla la decisión de la aplicación de reconstruir.
Decide qué información mirar y cuál ignorar.
Makepp generalmente elige el método de verificación de compilación correcto automáticamente. Sin embargo, puedes
cambiar el método de firma para una regla individual usando: modificador build_check en el
regla, o para todas las reglas en un archivo MAKE utilizando la instrucción build_check, o para todas
makefiles a la vez usando la opción de línea de comando -m o --build-check-method.
Los datos utilizados para decidir sobre una reconstrucción o un repositorio o la importación de caché de compilación se almacenan en
el archivo de información de compilación interna. Puede mostrarlo con makeppinfo, mppi. Debajo de cada
El método da un ejemplo de cómo ver sus claves.
Build check métodos incluido in los
En la actualidad, hay cinco métodos de verificación de compilación incluidos en la distribución:
coincidencia exacta
Este método utiliza las fechas de modificación del archivo como firmas. Reconstruye el
objetivos a menos que se cumplan todas las condiciones siguientes:
· La firma de cada dependencia es la misma que estaba en la última compilación.
· La firma de cada objetivo es la misma que en la última compilación (es decir, nadie
se ha metido con los objetivos desde que makepp los construyó).
· El comando de construcción no ha cambiado.
· La arquitectura de la máquina (o lo que Perl cree que es) no ha cambiado.
"exact_match" es el método predeterminado a menos que esté reconstruyendo un Makefile (ver más abajo).
Esta es una forma altamente confiable de garantizar construcciones correctas, y casi siempre es lo que
quieres. Sin embargo, tiene algunos efectos secundarios que pueden resultar sorprendentes:
· Si ha estado compilando con la marca tradicional y luego cambia a makepp,
todo se vuelve a compilar la primera vez que ejecuta makepp.
· Si daña la información de makepp sobre lo que sucedió en la última compilación (por ejemplo,
eliminas el subdirectorio ".makepp" o no lo copias cuando copias todo
else), se activa una reconstrucción.
· Si reemplaza un archivo con una versión anterior, se activa una reconstrucción. Este es
normalmente lo que quieres, pero puede resultar sorprendente.
· Si modifica un archivo fuera del control de makepp (por ejemplo, ejecuta el
compilación usted mismo), luego makepp reconstruirá el archivo la próxima vez. (Si
desea evitar esto, consulte la opción de línea de comando "--dont-build").
· Los archivos independientes de la arquitectura se reconstruyen cuando cambia a una
arquitectura. Por lo general, esto no es un problema, porque a menudo no toman mucho tiempo.
para construir. La razón por la que todos los archivos están etiquetados con la arquitectura, en lugar de
solo archivos binarios, es que a menudo incluso los archivos ASCII son arquitectura-
dependiente. Por ejemplo, la salida del programa "lex" de Solaris no se compilará en
Linux (o al menos esto solía ser cierto la última vez que lo probé).
Concretamente, un archivo no se reconstruirá ni se podrá recuperar del repositorio o compilar
caché, si la siguiente salida del comando permanece igual, es decir, coincide con las firmas de
las dependencias:
mppi -k'COMMAND ARCH SORTED_DEPS DEP_SIGS ENV_ {DEP, VAL} S 'archivo
arquitectura_independiente
El método "architecture_independent" es el mismo que "exact_match" excepto que lo hace
No revise la arquitectura. Esto puede resultar útil para archivos independientes de la arquitectura,
que no es necesario reconstruir cuando se cambia a una arquitectura diferente. Para
ejemplo, probablemente no necesite volver a ejecutar "bison" en Solaris si ya lo ejecutó en
Linux.
El método "architecture_independent" se utiliza mejor si se especifica mediante el
": build_check architecture_independent" modificador para cada regla que produce
archivos independientes de la arquitectura. Makepp por defecto nunca asume que los archivos son
arquitectura independiente, porque incluso .c los archivos pueden depender de la arquitectura. Para
ejemplo, la salida de Solaris lex no se compilará en Linux, o al menos
no sería la última vez que lo intenté. Por lo tanto, debe especificar manualmente este método de verificación de compilación para
cualquier archivo que sea verdaderamente independiente de la arquitectura.
Concretamente, un archivo no se reconstruirá ni se podrá recuperar del repositorio o compilar
caché, si la siguiente salida del comando permanece igual, es decir, coincide con las firmas de
las dependencias:
mppi -k'COMMAND SORTED_DEPS DEP_SIGS ENV_ {DEP, VAL} S 'archivo
ignorar_acción
El método "ignore_action" es el mismo que "exact_match" excepto que no marca
la cadena de acción (el comando). A veces, un comando puede cambiar y no quieres
forzar una reconstrucción.
Por ejemplo, es posible que desee poner explícitamente una fecha en su comando para registrar cuándo
se realizó la compilación, pero no desea forzar una reconstrucción cada vez que se ejecuta el comando
ejecutado. Por ejemplo,
BUILD_DATE: = $ (fecha de la cáscara)
mi_programa: $ (MÓDULOS) .o
$ (CXX) $ (entradas) -DBUILD_DATE = "\" $ (BUILD_DATE) \ "" fecha_stamp.c -o $ (salida)
Esto compilará fecha_stamp.c con el último sello de fecha de compilación, pero no forzará un
recompilar cuando cambie la fecha. Desafortunadamente, si hay algo más sobre el enlace
cambios de comando (por ejemplo, cambia las opciones del enlazador), tampoco desencadenará una reconstrucción.
Esto también es útil junto con $ (modified_inputs) o $? variable para
acciones que simplemente actualizan un objetivo, en lugar de reconstruirlo desde cero. Para
ejemplo, podría actualizar un archivo .a como este:
libmine.a: * .o: build_check ignore_action
$ (AR) ru $ (salida) $ (entradas_cambiadas)
Esto seguirá funcionando principalmente si se olvida de especificar el ": build_check
ignore_action ". Sin embargo, suponga que ninguno de los archivos .o ha cambiado. El comando
ahora será "ar ru libmine.a" que probablemente sea diferente de lo que era la última vez
(por ejemplo, "ar ru libmine.a buggy_module.o"), entonces makepp ejecutará el comando. En esto
caso, el comando no hará nada excepto perder tiempo.
No se recomienda la creación de archivos .a como este, ya que puede dejar archivos .o obsoletos dentro
el archivo. Si elimina un archivo de origen, el archivo .o todavía está dentro del archivo .a,
y esto puede dar lugar a construcciones incorrectas. Es mejor crear un archivo .a como este:
libmine.a: * .o
& rm $ (salida)
$ (AR) ru $ (salida) $ (entradas)
Concretamente, un archivo no se reconstruirá ni se podrá recuperar del repositorio o compilar
caché, si la siguiente salida del comando permanece igual, es decir, coincide con las firmas de
las dependencias:
mppi -k'ARCH SORTED_DEPS DEP_SIGS ENV_ {DEP, VAL} Archivo S '
objetivo_nuevo
El método "target_newer" solo mira la fecha del archivo. Si alguna dependencia es mas
más reciente que el objetivo, el objetivo se reconstruye. Este es el algoritmo que
Unix tradicional “piensen de nuevo sobre los incrementos de precio” usos de servicios públicos.
El método "target_newer" no es tan seguro como el método "exact_match" porque no
desencadenar una reconstrucción si cambia el comando de compilación, o si reemplaza un archivo con un
versión antigua. A veces también puede confundirse si los relojes no están correctamente
sincronizado. Por ejemplo, si un archivo de alguna manera obtiene la fecha del 4 de junio de 2048, entonces
entre ahora y 2048, todos los archivos que dependen de ese archivo se reconstruirán aunque
el archivo no cambia. Además, cambiar a una arquitectura diferente no activará
reconstruir. Evita recuperar el destino de una regla de una caché de compilación, porque no hay
firma única que se puede asociar al sinfín de pares que cumplen el
relación más reciente que.
Pero hay algunos casos en los que es posible que desee utilizar el método "target_newer":
· Cuando es razonable que un usuario cree un archivo fuera del control de makepp.
Quizás el ejemplo más común son los comandos que generan el archivo MAKE
en sí mismo, es decir, el procedimiento de autoconfiguración. Los usuarios suelen emitir la configuración
comando manualmente, pero los archivos MAKE a menudo tienen una forma de actualizarse
automáticamente. En este caso, no queremos forzar la reconstrucción del archivo MAKE.
en sí mismo si el usuario escribió el comando manualmente, por lo que el método "target_newer" es
más apropiado que el método "exact_match". De hecho, si makepp está intentando
crea un archivo MAKE, hace que "target_newer" sea el método predeterminado hasta que haya terminado
construyendo el archivo MAKE.
· Cuando es razonable que un usuario modifique un archivo después de que makepp lo haya construido. Para
Por ejemplo, si un archivo no existe, es posible que desee copiarlo desde una central
ubicación, o compruébelo en un repositorio; pero el usuario debe poder
modificarlo. Si utiliza el método de verificación de compilación predeterminado "exact_match", makepp
detectar que el usuario ha cambiado el archivo y, por lo tanto, forzará una copia nueva de
la ubicación central o una caja nueva, eliminando los cambios del usuario.
Si necesita verificar manualmente las marcas de tiempo, consulte los ejemplos de makeppinfo para obtener
el camino de cada dependencia.
solo_accion
El método muy específico "only_action" solo ejecutará la acción si el comando
cadena difiere de la última vez que se ejecutó. Por ejemplo,
$ (RAÍZ) / incluir /%. H:% .h
& ln -fr $ (entrada) $ (salida)
publica un archivo, pero no lo repite cuando cambia el archivo. Tenga en cuenta que & ln
El comando está incorporado y, por lo tanto, es barato, pero makepp aún tiene que desembolsar y monitorear un
proceso para realizar toda la acción. Entonces, si tiene muchos archivos para publicar,
sigue siendo un beneficio. En realidad, no especificamos el método, porque, cuando el objetivo
es un enlace simbólico, esta comprobación de compilación se utiliza automáticamente. Solo necesitas
especificarlo para otros comandos que dependen únicamente del comando (que generalmente
contiene los nombres de las entradas):
% .list:% .x: build_check only_action
& echo $ (entradas) -o $ (salida)
Concretamente, un archivo no se reconstruirá ni se podrá recuperar del repositorio o compilar
caché, si la siguiente salida del comando permanece igual, es decir, coincide con las firmas de
las dependencias:
archivo mppi -kCOMMAND
Son posibles otros métodos de verificación de compilación. Puede escribir su propio método de verificación de compilación mediante
creando un módulo "Mpp :: BuildCheck :: MyMethod". Lea la documentación en
Mpp / BuildCheck.pm en la distribución de makepp. Lo más probable es que desee su verificación de compilación
método para heredar de "Mpp :: BuildCheck :: exact_match", así que lea su documentación también.
Es más útil modificar el mecanismo de firma que modificar la verificación de compilación
mecanismo directamente. Antes de cambiar el mecanismo de verificación de compilación, vea si su problema es
mejor servido cambiando firmas (ver makepp_signatures para más detalles).
Estas son algunas de las razones por las que un método de verificación de compilación personalizado puede ser útil:
· Si desea que makepp ignore parte del comando. Por ejemplo, si tiene comandos
en su archivo MAKE así:
xo: xc
ssh $ (MÁQUINA_DEL_MOTO) cc $ <-o $ @
es posible que desee que makepp no fuerce una reconstrucción si cambia "$ (REMOTE_MACHINE)". usted
podría modificar el método "exact_match" para que conozca los comandos ssh e ignore los
nombre de la máquina. Verificar: enviar por otra forma de lograrlo.
Use makepp_build_check en línea usando los servicios de onworks.net