Recursive Make - ¿amigo o enemigo?

Estoy usando (GNU) Hacer en mi proyecto. Actualmente estoy poniendo un archivo MAKE por directorio y especifico los subdirectorios usando SUBDIRS. Se me ha sugerido que esta no es la forma ideal de usar make, que al usar un archivo make de un nivel (o varios, se divide usando include). Intenté migrar/usar este diseño en el pasado, pero me parece que no es complicado.Recursive Make - ¿amigo o enemigo?

¿Cuáles son los beneficios/inconvenientes de utilizar archivos make recursivos?

Fuente

2008-11-26 Johan Dahlin

Lo primero que debe tener en cuenta (solo para eliminar cualquier malentendido) es que no estamos hablando de un único o de varios archivos MAKE. Dividir su archivo MAKE en uno por subdirectorio es probablemente una buena idea en cualquier caso.

Los archivos make recursivos son malos principalmente porque usted divide su árbol de dependencias en varios árboles. Esto evita que las dependencias entre las instancias make se expresen correctamente. Esto también hace que (parte de) el árbol de dependencias sea recalculado varias veces, lo cual es un problema de rendimiento al final (aunque generalmente no es grande).

Hay un par de trucos que debe usar para utilice correctamente el enfoque de fabricación única, especialmente cuando tiene una base de código grande:

Primero, use GNU make (ya lo hace, veo). GNU make tiene una serie de características que simplifican las cosas, y no tendrá que preocuparse por las compatibilidades.

En segundo lugar, use valores de variables específicos del objetivo.Esto le permitirá tener, por ejemplo, diferentes valores de CFLAGS para diferentes objetivos, en lugar de obligarle a tener un solo CFLAGS en todo su maquillaje:

main: CFLAGS=-O2 
lib: CFLAGS=-O2 -g

En tercer lugar, asegúrese de usar VPATH/vpath a la completa medida soportada por GNU make.

También quiere asegurarse de que no tiene varios archivos de origen con el mismo nombre. Una de las limitaciones de VPATH es que no le permite tener definiciones de VPATH específicas del objetivo, por lo que los nombres de sus archivos de origen deberán coexistir en un solo "espacio de nombres de VPATH".

Fuente

2008-11-26 12:26:03 JesperE

¡Gran respuesta, gracias! En realidad, estoy usando VPATH incluso para un proyecto que usa archivos make recursivos, hace que sea mucho más fácil, especialmente para compilaciones srcdir! = Builddir. –

El beneficio que obtuve de esto en el pasado es que es más fácil construir archivos en un solo subdirectorio. Puede hacer esto con dependencias, pero es un poco más trabajo mantener todos los objetivos en línea recta. Básicamente, esto hace que sea más fácil hacer cambios y probar una biblioteca sin tener que lidiar con la complejidad total del proyecto más grande.

Fuente

2008-11-26 05:46:10

Tienes razón. Reutilización más fácil de objetivos comunes es otra ventaja –

-1

El problema con la marca recursiva es la sobrecarga de tiempo de la evaluación de los diferentes archivos make frente a la evaluación de un archivo make grande. Parte de esto son solo procesos de desove, pero también (IIRC) se te fuerza a asumir que otros hacen que los archivos hagan algo y reconstruir cuando realmente no es necesario.

Mi opinión es tener un único archivo make por "Unidad", que equivale más o menos a tener un archivo make para cada fragmento de código que espera que se pueda usar por sí mismo (por ejemplo, como una biblioteca independiente)

OTOH mi proyecto actual rompe esto por todas partes ya que estoy generando archivos make durante la compilación. : b

Fuente

2008-11-26 05:53:55 BCS

No, el tiempo no es el mayor problema. El mayor problema es dividir el árbol de dependencias en varios árboles de dependencias, lo que le impide expresar dependencias en subcategorías. – JesperE

IMNSHO es la única razón por la que incluso le importan las dependencias en absoluto * is * time. Si no te importa el tiempo, simplemente hazlo desde cero, reconstruye la pizarra en blanco todo el tiempo. Puede obtener dependencias "correctas" expresadas mediante codificación, de modo que si algo cambia, se supone que todo cambió, pero lleva más tiempo. – BCS

Puede encontrar un artículo titulado "Recursive Make Harmatful" (Recursivo Hacer Considerado Nocivo) aquí: http://miller.emu.id.au/pmiller/books/rmch/?ref=DDiyet.Com. (O en el proyecto Aegis en SourceForge.)

Explora los problemas con los archivos make recursivos y recomienda un enfoque de archivo único.

Fuente

2008-11-26 06:06:43

Esa es una buena referencia, gracias por señalarlo. –

Desafortunadamente, el enlace al documento real está dando un 500. –

El enlace al papel parece estar bien ahora. –

Para lanzar en una tercera opción, puede usar GNU Autotools. Se usa principalmente por otros motivos, pero también puede ser útil para organizar una creación de múltiples directorios.

http://www.lrde.epita.fr/~adl/autotools.html

Se ha de señalar, sin embargo, que el resultado es una versión recursiva.

Fuente

2008-11-26 06:13:24 ypnos

En realidad estoy usando autotools, pero puede usar tanto el modo recursivo como el no recursivo. –

Ejecute, no camine, al cmake.org y obtenga Cmake, una de las mejores herramientas de compilación disponibles.

Seguirás usando GNU make, pero en este caso CMake generará los makefiles por ti.

No puedo garantizar el 100%, pero todavía tengo que encontrarme con un caso donde no ha manejado correctamente las dependencias entre subdirectorios correctamente (es decir, el problema que afecta a la marca recursiva). Por lo menos, es mucho más fácil mantener Cmakefiles que makefiles. Muy recomendable.

No use GNU autotools - ¡de esa manera la locura yace!

Fuente

2008-11-26 12:46:43 Alastair

Ya conozco muy bien las autotools de GNU y me estoy volviendo cada vez más viejo para aprender un nuevo sistema. Tal vez en otros 5 años :-) –

CMake vale la pena el esfuerzo necesario para aprender. Es mucho más fácil que Autotools, y su soporte multiplataforma es mucho mejor. –

He encontrado que tiene una curva de aprendizaje mucho más superficial que CMake. La sintaxis de CMake está en constante cambio, la documentación es horrible y, al final, aún no es capaz de encontrar automáticamente las ubicaciones de las bibliotecas comunes conectadas a los sistemas, por lo que busca constantemente "FindLibraryXYZ.CMake" scripts de cmake para incluir con su proyecto. No tiene nada de elegante, así que solo úsela si realmente la necesita. Perdón por la diatriba. –

Makepp es tu amigo.

http://makepp.sourceforge.net/

Compatible con maquillaje
de escaneo automático para las dependencias de cabecera
manejo ordenado del árbol de directorios

Fuente

2011-04-14 17:09:13

utilizo ampliamente recursividad. cada nodo hoja tendrá su propio archivo MAKE, considere:

$LIBS = libfoo libbar 
$(LIBS): 
    cd [email protected] && $(MAKE)

En sistemas grandes sería todo un reto para no tener esta estructura. Lo que la gente dice sobre "recursivo hace que se considere dañino" es una evaluación precisa. Creo que cada situación es un poco diferente y hacemos algunos compromisos.

Fuente

2011-05-05 06:12:48 Kramer

Recursive Make - ¿amigo o enemigo?

Respuesta

Cuestiones relacionadas