Evite la recompilación con git y make

Question

Tengo dos ramas de desarrollo en git y con frecuencia necesito cambiar entre las dos. Sin embargo, lo realmente frustrante es que cada vez que cambio ramas en git, todo el proyecto se reconstruye porque las marcas de tiempo del sistema de archivos de algunos archivos cambiarán.

Ofc, los makefiles están configurados para construir el proyecto en dos directorios de compilación diferentes.

¿Hay alguna forma de evitar esto? La compilación es un proceso muy largo y lento ...

Editar: - Esta es una explicación un poco más detallada de la pregunta ... Digamos que tengo un encabezado de archivos Basic.h que está incluido en una serie de otros archivos. Basic.h es diferente entre la rama 1 y la rama 2.

Ahora digamos que he compilado la rama 1 en build_branch1 y la rama 2 en build_branch2. Digamos que tengo la rama 2 actualmente prestada. Ahora comprobo la rama 1 y cambio File1.cpp y vuelvo a compilar. Idealmente, dado que File1.cpp solo ha cambiado desde que lo compilé por última vez, este es el único archivo que debe recompilarse.

Sin embargo, como Basic.h ha cambiado su marca de tiempo debido a la finalización de la compra, todos los archivos que incluyen Basic.h se volverán a compilar. Quiero evitar esto.

Answer 1

Git solo cambia los archivos que se actualizan entre las ramas. Pero si su compilador realiza una reconstrucción completa incluso si se modificó un único archivo, siempre puede clonar y verificar sus diferentes ramas en directorios diferentes. Es como:

/your-repo-name.branch1 
/your-repo-name.branch2 

Esto ocupa más espacio en disco pero es mucho más conveniente que cambiar ramas divergentes en un gran repositorio.

Answer 2

Si sabe qué archivos realmente necesitan compilación, y los hace manualmente, GNU Make (al menos, no sé sobre otras implementaciones) tiene una marca: -t, que básicamente ejecuta su Makefile y cambia las marcas de tiempo en su lugar de ejecutar comandos.

No obstante, deberá actualizar los archivos que necesidad de actualización antes de usar esta bandera, o que va a terminar con ficheros de objetos que son legítimamente fuera de fecha, pero mirada actualizada. Consulte el documento vinculado para obtener más detalles.

La opción -o también podría interesarle, dependiendo de la cantidad de cambios cuando cambie de ramas.

Answer 3

No hay una buena manera de conservar las marcas de tiempo y no meterse en problemas en su entorno de compilación. Utilice git clone/git checkout branchB para crear un segundo directorio de trabajo para compilar y trabajar con la rama B. No tenga su compilación Makefile, haga que cada compilación se cree en su propio directorio de compilación.

Answer 4

Si Basic.h realmente difiere entre las ramas, entonces la única solución es dividirlo en archivos más pequeños con dependencias más finas, para que se reconstruyan menos cosas cuando cambie.

Pero supongamos que Basic.h es exactamente el mismo entre las ramas, pero git está cambiando su marca de tiempo. Este es un desencadenador falso, como hacer touch Basic.h, que revela una limitación de los sistemas de compilación basados ​​en la fecha y hora. Idealmente, queremos un sistema de compilación para reconstruir cuando los contenidos cambian, no cuando las marcas de tiempo cambian. Las marcas de tiempo se utilizan porque son un sustituto barato para detectar un cambio de contenido.El método superior es que el sistema de compilación mantenga hashes de todos los archivos y detecte modificaciones reales, sin tener en cuenta la marca de tiempo. Esto también soluciona problemas como "reloj sesgado detectado, su construcción puede estar incompleta".

No obtendrá este tipo de sistema de compilación de Make; pero es posible que pueda trabajar algunos aspectos con respecto a ciertos archivos. Por ejemplo, puede escribir sus reglas de Make para que sus archivos de objeto no dependan directamente de Basic.h, sino de Basic.h.sha, que es un archivo de sello. Ahora, ¿qué hay en Basic.h.sha? Este archivo contiene un hash SHA256 de Basic.h.

Cada vez que ejecuta Make, la lógica en el Makefile calcula el hash en Basic.h y lo compara con el hash almacenado en Basic.h.sha. Si difieren, entonces se sobrescribe Basic.h.sha con el nuevo hash. Por lo tanto, su sello de tiempo se golpea, lo que provoca una reconstrucción.

BASIC_H_SHA := $(shell sha256sum Basic.h) 
BASIC_H_SHA_OLD := $(shell cat Basic.h.sha) 

ifneq ($(BASIC_H_SHA),$(BASIC_H_SHA_OLD)) 
$(info Basic.h has changed!) 
DUMMY := $(shell echo "$(BASIC_H_SHA)" > Basic.h.sha) 
endif 

He implementado lógica a lo largo de estas líneas para hacer dependiente de módulos sobre los cambios a su respectiva CFLAGS. Básicamente, podemos convertir un cambio en cualquier cosa en un toque de un archivo de marca de tiempo, que controla lo que está construido.

Answer 5

Otra respuesta parcial: caché del compilador.

Al volver a la rama original y reconstruir, aunque las dependencias dicen que se deben reconstruir numerosos archivos dependientes de Basic.h, los archivos del objeto se pueden extraer de una memoria caché del compilador.

ccache (http://ccache.samba.org/) todavía tiene que hacer un trabajo bastante caro (procesar la unidad de traducción preprocesada, ya que una unidad de traducción completa se usa una clave hash) pero es mucho más barato que compilar.

En algunos casos ccache puede eliminar una compilación frente a un cambio que no lo afecta, como algunos cambios en el espacio en blanco. Por ejemplo, si cambia un comentario en un archivo dependiente (encabezado o fuente), eso no invalida el archivo del objeto en caché.

Por lo tanto, puede ayudar incluso si hace un git pull y elige un cambio nuevo en Basic.h que no haya visto antes.