¿Por qué las construcciones incrementales en "make" no usan algoritmos de hash?

7

Soy un principiante con make y me pregunto cuándo usar make clean .

Un colega me dijo que las compilaciones incrementales con make se basan en las marcas de tiempo de los archivos. Por lo tanto, si selecciona una versión anterior de un archivo en su VCS, tendrá una marca de tiempo "antigua" y se marcará como "no es necesario recompilar este archivo". Entonces, ese archivo no se incluiría en la siguiente compilación.
Según ese mismo colega, sería una razón para usar make clean .

De todos modos, obtuve la respuesta a la pregunta "cuándo usar make clean " de otras preguntas de StackExchange, pero mi otra pregunta es:

  

¿Por qué las construcciones incrementales que utilizan make se basan en las marcas de tiempo de los archivos y no en SHA-1, por ejemplo? Git, por ejemplo, muestra que podemos determinar con éxito si un archivo se modificó con el SHA-1.
  ¿Es por cuestiones de velocidad?

    
pregunta filaton 24.05.2016 - 17:42

2 respuestas

3

Un problema obvio (y posiblemente superficial) sería que el sistema de compilación tendría que mantener un registro de los hashes de los archivos que se usaron para la última compilación. Si bien este problema podría resolverse, requeriría un almacenamiento lateral cuando la información de la marca de tiempo ya esté presente en el sistema de archivos.

Más seriamente, sin embargo, el hash no transmitiría la misma semántica. Si sabe que el archivo T se creó a partir de la dependencia D con hash H 1 y luego descubra que D ahora hash a H 2 , ¿deberías reconstruir T ? Probablemente sí, pero también podría ser que H 2 en realidad se refiera a una versión más antigua del archivo. Los sellos de tiempo definen un orden, mientras que los hashes solo son comparables para la igualdad.

Una función que admiten las marcas de tiempo es que puede actualizar la marca de tiempo (por ejemplo, utilizando la utilidad de línea de comandos POSIX touch ) para engañar a make para que piense que una dependencia ha cambiado o, lo que es más interesante, que un objetivo es más reciente de lo que realmente es. Mientras que jugar con esto es una gran oportunidad para dispararte a ti mismo en el pie, es útil de vez en cuando. En un sistema basado en hash, necesitaría soporte desde el propio sistema de compilación para actualizar su base de datos interna de hashes utilizados para la última compilación sin construir realmente nada.

Si bien se podría hacer un argumento para usar hashes en sellos de tiempo, mi punto es que no son una mejor solución para lograr el mismo objetivo, sino una solución diferente para lograr un objetivo diferente. Cuál de estos objetivos es más deseable podría estar abierto a debate.

    
respondido por el 5gon12eder 25.05.2016 - 02:54
1

Hashing un proyecto entero es muy lento. Tienes que leer cada byte de cada archivo. Git no hash todos los archivos cada vez que ejecutas un git status tampoco. Las comprobaciones de VCS tampoco establecen normalmente la hora de modificación de un archivo a la hora original de creación. Una restauración de copia de seguridad sería, si tiene cuidado de hacerlo. La razón por la que los sistemas de archivos tienen marcas de tiempo es para casos de uso como estos.

Por lo general, un desarrollador ejecuta make clean cuando cambia una dependencia no controlada directamente por Makefile. Irónicamente, esto usualmente incluye el propio Makefile. Por lo general, también incluye versiones de compilador. Dependiendo de qué tan bien esté escrito su Makefile, podría incluir versiones de la biblioteca externa.

Estos son el tipo de cosas que tienden a actualizarse cuando se realiza una actualización de control de versión, por lo que la mayoría de los desarrolladores simplemente adquieren el hábito de ejecutar make clean al mismo tiempo, para que sepa que está comenzando desde un pizarra limpia Puedes escapar sin hacerlo mucho tiempo, pero es realmente difícil predecir los tiempos en que no puedes.

    
respondido por el Karl Bielefeldt 24.05.2016 - 19:53

Lea otras preguntas en las etiquetas