makepp_repositories: en línea en la nube

PROGRAMA:

NOMBRE

makepp_repositories: cómo usar repositorios para compilaciones variantes, para mantener un
conjunto central de fuentes y otras cosas

DESCRIPCIÓN

A repositorio es un directorio o una jerarquía de directorios fuera del directorio predeterminado que
contiene archivos que necesita el archivo MAKE en el árbol de directorios actual. Makepp puede
vincular automáticamente archivos del repositorio al árbol de directorios actual si están
necesario. Los repositorios proporcionan una funcionalidad similar a la variable "VPATH", pero (a diferencia de
"VPATH" en otras versiones de make) no tienes que hacer nada especial en tu makefile
para que funcionen.

Los repositorios se especifican con la opción de línea de comandos "-R" o "--repository" o con la
instrucción "repositorio" en el archivo MAKE. Tenga en cuenta que si tiene la costumbre de llamar a makepp
en diferentes subdirectorios de su árbol de compilación, es fácil reimportar accidentalmente un
repositorio en otro lugar. Como salvaguardia contra esto, si usa Archivo RootMakepp, hacer pp
se negará a comenzar si encuentra uno arriba o abajo de donde se importaría.

Esto es algo comparable a los sistemas de archivos de unión del sistema operativo (unionfs ...).
El directorio actual es como la capa de escritura de nivel más alto. Todos los repositorios son como
capas inferiores de solo lectura.

Los repositorios son útiles en varias situaciones diferentes:

· Cuando desee colocar su objeto y archivos ejecutables en un directorio separado, pero
el archivo MAKE está escrito para colocarlos en el mismo directorio que las fuentes.

· Cuando desee crear el mismo programa de dos formas diferentes (p. Ej., Con dos
conjuntos de opciones de compilación, o para dos arquitecturas diferentes).

· Cuando no tiene acceso de escritura a todo o parte del árbol de fuentes.

· Cuando varios desarrolladores están trabajando en el mismo proyecto y hay una fuente común
repositorio que contiene todas las fuentes del proyecto. Cada desarrollador puede modificar solo
los archivos que necesita cambiar en su directorio local sin afectar al otro
desarrolladores, y makepp buscará automáticamente los archivos no modificados de la fuente
repositorio.

La implementación de repositorios de Makepp no ​​requiere la reescritura de los comandos de compilación
en absoluto, a diferencia (por ejemplo) de los repositorios en contras. Makepp pone un enlace simbólico en el
directorio donde el comando lo espera. Siempre que el comando no se refiera a
directorios absolutos, exactamente el mismo comando de shell funcionará con archivos de un repositorio.
Esto significa que no solo funciona para los comandos de compilación, sino también para cualquier tipo de comando que
puede pensar en poner en su archivo MAKE.

Makepp tiene otro tipo de mecanismo llamado construimos cache que resuelve algunos de los mismos
tipos de problemas como repositorios de una manera diferente. Dependiendo de su problema, una compilación
La caché puede ser más útil que un repositorio. Consulte makepp_build_cache para obtener información sobre
build caches y una comparación de build caches y repositories.

Ejemplos
Los repositorios se explican mejor con varios ejemplos de lo que puede hacer.

diferente compilación opciones

Suponga que tiene un programa simple con un archivo MAKE que se parece a esto:

FLAGS = -O2
OBJETOS = ao bo co
mi_programa: $ (OBJETOS)
cc $ (entradas) -o $ (salida)

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

Este archivo MAKE coloca los archivos "ao", "bo", "co" y "my_program" en el mismo directorio
como archivos de origen.

A veces, desea colocar los archivos binarios en un directorio separado. Por ejemplo tu
podría construir su programa en varias arquitecturas diferentes, y no quiere el binario
archivos en una arquitectura para ser reemplazados por archivos binarios en la otra. O podrías
desea hacer un cambio temporal y volver a compilar sin borrar la compilación anterior
resultados. Sin repositorios, tendría que modificar su archivo MAKE para colocar el
objetos en otros lugares.

Sin embargo, con un repositorio, no tienes que tocar tu archivo MAKE en absoluto. Considera el
siguiente secuencia de comandos:

% cd mi_programa_fuente
% makepp # Construye usando el archivo MAKE anterior, y
# archivos de objeto van al directorio
# mi_programa_fuente.
% CD ..
% mkdir binary-debug # Crea un directorio limpio para construir el
% cd binary-debug # mismo programa con diferentes opciones.
% makepp -R ../my_program_source CFLAGS = -g
# Ahora los objetos entran en depuración binaria.

El primer comando makepp compila los archivos fuente con optimización y coloca los objetos
en el directorio "my_program_source", porque eso es lo que se supone que debe hacer el archivo MAKE
hacer. Ahora queremos reconstruir el programa, pero queremos cambiar el valor de "CFLAGS" a
compilar para depurar. Especificamos el nuevo valor de "CFLAGS" en la línea de comando, y también
dígale a makepp que el directorio "my_program_source" es un repositorio usando la opción "-R".

Cada vez que makepp se da cuenta de que necesita un archivo que aún no tiene en la
directorio, busca en el repositorio. En este caso, primero busca el archivo MAKE,
que no existe en el subdirectorio "binary-debug". Entonces crea un enlace simbólico a
desde el archivo MAKE en "my_program_source", y luego lo lee en el archivo MAKE. Entonces eso
advierte que necesita el archivo "ac" para construir "ao", por lo que se vincula en "ac"
desde el repositorio. Si "ac" incluye cualquier archivo contenido en "my_program_source", entonces
estos también se vincularán automáticamente. Nota: esos enlaces son útiles para cosas
como depurar, pero si no le gustan, "makeppclean -R" puede eliminarlos.

Ejecutar el comando de compilación en "binary-debug" no tocará ninguno de los archivos en
"my_program_source". Por lo tanto, del mismo conjunto de archivos fuente, ahora tiene dos
copias del programa, una compilada con optimización y otra compilada para depuración. Y
esto sucedió sin tocar el archivo MAKE en absoluto.

La ventaja de usar repositorios en lugar de simplemente volver a compilar y sobrescribir el
binarios originales es que ahora, si arreglamos nuestros errores y queremos volver a la versión optimizada
versión, no tenemos que volver a compilar todo. Dado que los archivos de objeto originales todavía
alrededor, y la mayoría de ellos siguen siendo válidos, podemos ahorrar mucho tiempo en la recompilación.
Esto no hace una gran diferencia cuando solo se involucran tres archivos fuente, pero para un
construcción más grande que tarda minutos u horas en completarse, los ahorros en el tiempo del programador y
la frustración puede ser significativa.

Reconstrucción uno presentar con a menor de edad modificación a la compilación comandos

Makepp no ​​recupera solo los archivos fuente del repositorio. Si los archivos de objeto en el
el repositorio no necesita reconstruirse, los usará. Por ejemplo, considere un ligero
modificación al archivo MAKE anterior:

CFLAGS: = -O2
A_CFLAGS: = -O6 -funroll-loops

OBJETOS: = ao bo co

mi_programa: $ (OBJETOS)
cc $ (entradas) -o $ (salida)

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

ao: ac
cc $ (A_CFLAGS) -c $ (entrada) -o $ (salida)

La idea es que "ao" contenga el código de tiempo crítico, por lo que se compila con mayor
optimización que el resto de los objetos. Ahora suponga que queremos probar cuán diferente es
el tiempo es con diferentes opciones de compilación. Un repositorio también puede ayudar con esto:

% cd mi_programa_fuente
% makepp # Construye usando el archivo MAKE anterior, y
# archivos de objeto van al directorio
# mi_programa_fuente.
% CD ..
% mkdir no-unrolling # Crea un directorio limpio para construir el
% cd no-unrolling # mismo programa con diferentes opciones.
% makepp -R ../my_program_source A_CFLAGS = -O2
% CD ..
% time no-unrolling / my_program # Evalúe las dos versiones del programa.
% tiempo my_program_source / my_program

Makepp procede como antes, vinculando una copia del archivo MAKE y luego examinando el objeto
archivos. Ahora solo es necesario volver a compilar el módulo "ao", ya que las opciones para "bo" y "co"
no ha cambiado. Makepp advierte que puede usar "bo" y "co" del repositorio, por lo que
simplemente los vincula. Sin embargo, volverá a compilar "ao" en el directorio "no-unrolling".
Una vez finalizada la compilación, las dos versiones diferentes del programa se pueden
comparado.

Reconstrucción con a menor de edad modificación a la fuente

Ahora suponga que queremos hacer un cambio a "ac" y comparar el programa antes y después
el cambio. Los repositorios pueden volver a ayudar. Considere esta secuencia de comandos:

% mkdir modificado-a
% cp mi_fuente_programa / ac modificado-a
% cd modificado-a
% emacs ac # Realice algunas modificaciones solo en este módulo.
% makepp -R ../mi_programa_fuente

Aquí hemos creado un nuevo directorio que solo contiene el archivo fuente único que queremos
modificar. Makepp ahora toma "ac" del subdirectorio "modified-a", pero usa las copias de
"b" y "c" del directorio "my_program_source". Sin cambiar ninguno de los binarios
archivos en "my_program_source", hemos creado una copia separada del programa que
incorpora nuestros cambios a "ac". Si hay otros desarrolladores que utilizan las fuentes en
"my_program_source", no se verán afectados por nuestros cambios.

Por tanto, los repositorios se pueden utilizar como una forma rápida de crear variantes de un programa, sin
agregando condiciones complicadas al archivo MAKE. Ninguno de los archivos del original
se modifican el directorio; se utilizan según sea necesario.

Usando a directorio jerarquía

En realidad, un repositorio no es solo un directorio único, es una jerarquía de directorios completa.
Supongamos que usas / nuestra / biblioteca como repositorio. Ahora / nuestra / biblioteca bien puede contener muchos
subdirectorios, por ejemplo, / nuestra / biblioteca / gui y / nuestra / biblioteca / red. Considere este comando:

% makepp -R / nuestra / biblioteca

Cualquier comando en el archivo MAKE que se refiera a archivos en el directorio ./red realmente
obtener archivos de / nuestra / biblioteca / red, y de manera similar para ./gui. Makepp automáticamente
crea los directorios que existen en el repositorio pero no en el directorio actual.

Enlace a cualquier place in la presentar te

Todos los ejemplos anteriores muestran archivos de un repositorio vinculados al actual
directorio o sus subdirectorios, pero en realidad puede hacer que makepp los vincule a cualquier lugar
en el sistema de archivos al que tiene acceso de escritura. Esto se hace especificando
"-R nueva-ubicación = antigua-ubicación".

Por ejemplo, a veces es un poco tedioso escribir lo siguiente:

compilación alternativa de mkdir
cd construcción alternativa
makepp -R ..

Puedes hacerlo todo con un comando, como este:

makepp -R construcción-alternativa =. -F construcción alternativa

"-F" o "-makeppfile" cambia a ese directorio antes de cargar el archivo MAKE. Debes
especifique "-R" antes de "-F". Tenga en cuenta que este ejemplo coloca el nuevo árbol de compilación dentro del
repositorio. Eso no funcionará si usa un Archivo RootMakepp porque makepp salvaguarda
contra árboles anidados. Tampoco es una buena idea si usa **, porque si alguna vez construyes
en el repositorio también encontrará archivos editados y generados en este subárbol.

La asignación de una ubicación diferente en el sistema de archivos también puede ser útil para
builds, donde hay varios subdirectorios de bibliotecas. Por ejemplo, aquí hay un comando que
he usado para construir variantes de uno de mis programas:

% makepp -R prueba-compilación / seecape = / src / seecape \
-R prueba-compilación / HLib = / src / HLib \
-R prueba-compilación / H5pp = / src / H5pp \
-R qwt = / src / bibliotecas_externas / qwt \
-F prueba-construcción / seecape

Este comando carga archivos de cuatro repositorios diferentes y luego cds al
./test-build/seescape directorio y ejecuta el archivo MAKE allí. Archivos contenidos en el
árbol de directorio que comienza con / src / seecape están vinculados a ./test-build/seescape. En
otras palabras, makepp vinculará temporalmente el archivo /src/seescape/gui/image_canvas.cxx a
./test-build/seescape/gui/image_canvas.cxx cuando sea necesario. Este comando funcionará incluso
si el directorio "test-build" aún no existe; makepp lo creará por ti. (Pero tu
debe especificar las opciones "-R" antes de la opción "-F" en la línea de comando).

Múltiple equivalente repositorios

Digamos que su proyecto es mantenido por varios grupos bastante autónomos. Podrías tener uno
repositorio completo con todas las fuentes ya que están en producción o al menos
probado con éxito. Cada grupo puede tener un repositorio casi vacío con (parte de) el
misma estructura, que contiene los archivos que los miembros del grupo han terminado de desarrollar.

Los directorios actuales de los desarrolladores tendrán los archivos en los que todavía están trabajando. El grupo
El repositorio será el primero que se proporcione y el repositorio de producción el último, de modo que
proporciona los archivos que no se encuentran en el repositorio del grupo:

$ makepp -R / ruta / a / grupo / repositorio -R / ruta / a / producción / repositorio

Dado que esto probablemente sea bastante estático para ese directorio, es posible que desee colocar un archivo
.makepprc en su raíz con el siguiente contenido:

-R / ruta / a / grupo / repositorio -R / ruta / a / producción / repositorio

O, suponiendo que tenga una ruta fija, puede escribir en su archivo MAKE:

repositorio / ruta / a / producción / repositorio

y, debido a que las opciones se ven antes de que se lean los archivos MAKE, puede llamar simplemente

$ makepp -R / ruta / a / grupo / repositorio

Repositorios as fijas parte of Tu construimos te

Si sabe que siempre usa algún repositorio, puede usar el "repositorio" o "vpath"
declaraciones en su archivo MAKE.

Advertencias con repositorios
¿Cuándo? la enlaces get in la way

Para orientarse en la jerarquía de archivos y permitir que el depurador encuentre el
fuentes es útil tener los enlaces utilizados durante la construcción. Pero cuando quieres editar un
archivo o resincronizarlo con su control de versiones, los enlaces pueden interferir. Es decir
porque el sistema atraviesa el enlace y escribe en el archivo del repositorio. A no ser que
es su repositorio personal que se usa solo para mantener las cosas separadas, eso puede no ser lo que
querer.

Como salvaguardia contra la sobrescritura inadvertida de archivos públicos, se sugiere hacer
fuentes en el repositorio que no se pueden escribir. Incluso puede que no sea suficiente para eliminar la escritura
bit, porque un sistema de control de versiones que insiste en bloquear los archivos para editarlos
también podría hacer eso, pero hacer que el archivo se pueda escribir temporalmente mientras lo resincroniza. Si eso es
En su caso, el repositorio debería pertenecer a un usuario diferente.

Hay algunas tácticas para superar esto:

· Mantenga las fuentes que edita en un repositorio, separado de su árbol de compilación. Cuando sea
pones un archivo, que fue previamente obtenido de otro repositorio, en este
editando el repositorio, makepp lo notará y lo buscará desde allí, siempre que sea el
primer repositorio que especifique.

· Recuerde eliminar cualquier archivo, antes de crear una copia para escribir. Si sigues el
salvaguardar la sugerencia anterior, si se olvida de hacer esto, aparecerá un mensaje de error cuando
escribiendo. Para ayudarlo, la siguiente función "desvincular" reemplazará un vínculo por una copia
del archivo vinculado. La primera variante es para todo tipo de conchas Bournish, la segunda
uno para csh (o al menos tcsh):

$ desvincular () {{rm $ 1 && cat> $ 1; } <$ 1; }
% alias delink '(rm \ !: 1 && cat> \ !: 1;) <\ !: 1'

· Si cree que no los necesita, puede eliminarlos todos, cuando lo desee, p. Ej.
después de cada ejecución de makepp, posiblemente en segundo plano (ya sea en forma corta o larga):

makeppclean --recurse --only-repository-enlaces
mppc-rR

No construimos in a repositorio during use

Un repositorio está diseñado para ser de solo lectura mientras se utiliza como repositorio. Makepp lo hará
No funcionará correctamente si cambia archivos en su repositorio durante el transcurso de una compilación.
Las compilaciones nocturnas pueden estar bien para usted, si nadie más usa el repositorio en ese momento. Antes
inicia la compilación, makepp obtiene una lista de todos los archivos que existen en el repositorio, y
nunca actualiza su lista, a excepción de los archivos que espera aparecer.

Si necesita un repositorio que cambie a medida que construye, es posible que desee considerar makepp's
construir mecanismo de caché (ver makepp_build_cache). Alternativamente, puede utilizar un "hombre pobre
repositorio ": puede poner reglas explícitas en su archivo MAKE para crear los enlaces suaves, como
modo:

% .c: $ (directorio_I_deseo_was_a_repositorio) /%. c
& ln -fs $ (entrada) $ (salida)

Esto funciona solo para archivos fuente; no puede usar esto fácilmente para vincular un archivo si es
ya está integrado en el repositorio, pero constrúyalo aquí si aún no lo está, ya que no
solo se permite que sea una forma de crear un archivo.

Utilizar only relativo nombres de archivo

Los repositorios funcionan de forma completamente transparente if la hacer archivos use only relativo nombres de archivo.
En el ejemplo anterior, está bien si el archivo MAKE en / src / seecape se refiere a ../HLib, Pero el
El comando anterior no funcionará como se esperaba si se refiere a / src / HLib. Si necesita usar
nombres de archivo absolutos, puede ponerlos en make variables y luego anularlos en el
línea de comando, así:

% makepp -R prueba-compilación / seecape = / src / seecape SEESCAPE = / inicio / holt / prueba-compilación / seecape \
-R test-build / HLib = / src / HLib HLIB = / home / holt / test-build / HLib \
-R test-build / H5pp = / src / H5pp H5pp = / home / holt / test-build / H5pp \
-R qwt = / src / bibliotecas_externas / qwt QWT = / home / holt / test-build / qwt \
-F prueba-construcción / seecape

Lo anterior funcionará siempre que el directorio "HLib" se denomine "$ (HLIB)" en todos los
makefiles. Tenga en cuenta que debe especificar rutas absolutas para los directorios, porque
makepp cd's a "test-build / seecape" antes de leer el archivo make. Esto conduce a largos y
comandos de creación complicados; utilice rutas relativas cuando sea posible.

Makepp deben know de seguridad para el hogar que todas dependencias

Los repositorios no funcionarán si hay dependencias ocultas que makepp no ​​conoce
acerca de. (De hecho, hacer una compilación usando repositorios es una forma de verificar si se han olvidado
dependencias. Pero, solo para esta comprobación, no lo combine con un caché de compilación, ya que
buscar algo allí, en lugar de construirlo, podría ocultar una dependencia olvidada).
A veces, estas dependencias pueden ser bastante sutiles. Por ejemplo, el libherramienta el comando será
no solo crea archivos ".lo" y ".la" como se enumeran en la línea de comando, sino que también puede
cree un subdirectorio llamado ".libs" que contenga los archivos de objetos reales. Para prevenir
errores de compilación, makepp se niega a vincular en un archivo ".la" de un repositorio. Ojalá en
el futuro libtool estará mejor soportado.

Muchas dependencias ocultas relacionadas con la compilación son detectadas por el escáner de línea de comandos.
Si su compilador usa los indicadores de compilación comunes de Unix (por ejemplo, "-I", "-D", etc.), entonces
makepp generalmente averiguará dónde están todos sus archivos de inclusión. Puede que tengas que ser
tenga cuidado si tiene scripts de cosecha propia que crean archivos que makepp no ​​conoce
acerca de. Para construcciones correctas, es de vital importancia enumerar que todas objetivos y dependencias
(o determinarlos automáticamente escaneando).

Poniendo fotometría absoluta) nombres de archivo cobren programas

Los repositorios tampoco funcionarán si alguno de los archivos creados contiene nombres de archivo absolutos en
ellos (por ejemplo, si alguno de sus comandos de compilación escribe un nombre de archivo absoluto). Por ejemplo,
resulta que los archivos ".la" producidos por libherramienta tiene esta propiedad. (Si miras
el contenido del archivo ".la" verá que la lista de dependencias contiene valores absolutos
nombres de archivo.) Para resolver este problema en particular, makepp no ​​vinculará archivos ".la"
desde un repositorio; insistirá en reconstruirlos.

Evitando enlace in innecesario directorios

Los repositorios pueden ser lentos al iniciarse y usar mucha memoria si hay mucha
archivos innecesarios en el repositorio. Por ejemplo, si usa un HTML automático
generador de documentación que crea miles de archivos ".html" a partir de su código fuente,
es posible que no desee ponerlos en un subdirectorio de un directorio que se utiliza como repositorio.
Es mejor colocarlos en un árbol de directorios diferente por completo, por lo que el repositorio
el mecanismo no se cargará en sus nombres.

de más Muchos Archivos

La desventaja de los repositorios es que los enlaces simbólicos, que el mecanismo del repositorio
utiliza, son archivos individuales (aunque casi no usan espacio en disco). Esto es diferente a lo real
enlaces, pero no pueden cruzar los límites del sistema de archivos. En casos extremos, la presencia de
muchos enlaces simbólicos pueden llevar al agotamiento del número de archivos previstos (los llamados
inodos), aunque queda mucho espacio. En este caso, el administrador del sistema necesitará
para ajustar el sistema de archivos.

Primordial repositorio copias
Si realiza alguna modificación en un archivo localmente, makepp normalmente se dará cuenta de esto y
recompile el archivo usando la copia local en lugar de la copia del repositorio.

Si está utilizando un repositorio para mantener una base de código central y tiene desarrolladores
trabajando en copias locales que contienen solo los archivos que han modificado, un problema que
aparece es: ¿qué pasa si un desarrollador quiere eliminar un archivo de su compilación local pero el
el repositorio todavía lo contiene? Si el desarrollador elimina la copia local, makepp
coloque felizmente la copia del repositorio, y la compilación continuará como si el archivo
existió.

Una técnica (lamentablemente no para el usuario root) para este problema es hacer el archivo que desea
no incluir en el proceso de construcción ilegible, como este:

chmod a-rw archivo-a-excluirse

Esto evitará que makepp lo incorpore desde el repositorio. Makepp también incluye
código especial para que los archivos ilegibles no coincidan con comodines o reglas de patrón.

De manera similar, para evitar que makepp incorpore un subdirectorio completo, haga un local
directorio que tiene el mismo nombre pero no se puede escribir. Si quieres que makepp ignore el
directorio por completo, luego hágalo ilegible también. (Se buscan directorios de solo lectura pero
los objetivos en ellos generalmente no están construidos).

La otra forma de hacer esto es llamar a makepp con una o más opciones de exclusión:

mpp -R / ruta / a / rep --dont-read = / ruta / a / rep / archivo-a-excluirse

No use repositorios para archivos lo cual can ¡cambio!
No intente utilizar un repositorio para un archivo que es parte de su compilación. Por ejemplo tu
podría tener la tentación de intentar usar repositorios para poner todos sus archivos públicos .h en el mismo
directorio, así:

# archivo MAKE de nivel superior
repositorio include = module1 / include
repositorio include = module2 / include
repositorio include = module3 / include
repositorio include = module4 / include

Probablemente no sea una buena idea si cualquier del .h los archivos son en sí mismos salidas de un
programa (por ejemplo, yacc o algún otro programa que escupe código fuente C), porque makepp
asume que los archivos en los repositorios nunca cambian. Si la construcción necesita incluir / xyz.h y
module2 / include / xyz.h realmente necesita ser producido por algún programa, makepp no ​​sabrá
para ejecutar el programa. Es mejor usar una técnica como esta para poner todos tus .h archivos
en un directorio de inclusión común:

# module1 / Makeppfile
../include/%.h: incluye /%. h
& cp $ (entrada) $ (salida)
# También podría (de manera más eficiente pero problemática en Windows) hacer lo siguiente:
# & ln -r $ (entrada) $ (salida)

Makepp aún podría intentar crear archivos que estén en un repositorio si algo pregunta
para ellos directamente, pero no los construirá on favor del directorio local. El resultado
de esto puede ser bastante confuso, porque puede llevar a que un enlace simbólico de repositorio sea
utilizado mientras su destino de repositorio está desactualizado, pero ese destino podría actualizarse más tarde
en la construcción. Puede evitar que esto suceda asegurándose de que el
se hace referencia al repositorio only a través de la ruta del repositorio, o asegurándose de que no haya
también es una regla local para todos los archivos de repositorio generados.

Otra forma de evitar volver a compilar archivos idénticos en diferentes directorios es utilizar un
construir caché (ver makepp_build_cache para más detalles). Una caché de compilación no tiene la
restricción de que el archivo no puede cambiar.

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