Re: [Grulic-dev] Pregunta de Makefiles

Página superior
Adjuntos:
+ (text/plain)
Eliminar este mensaje
Responder a este mensaje
Autor: Cholo
Fecha:  
A: Daniel F Moisset
Cc: grulic-dev
Asunto: Re: [Grulic-dev] Pregunta de Makefiles
On 7/16/06, Daniel F Moisset <> wrote:
> --- Maxi Combina <> escribió:
> > Hola! tengo un problema (que describire a
> > continuacion). Busque
> > soluciones, pense diferentes alternativas, pero no
> > encontre algo que
> > sea 100% satisfactorio.
> > (...)
>
> Hay varias soluciones posibles: Una ya te la dijeron,
> probá con autoconf/automake. Otra es usar algun
> sistema de build distinto a mkae como scons. Otra es
> tener un solo Makefile grandote así:
>
> app: main.o dir1/a.o dir2/b.o
> main.o: dir1/a.h dir2/b.h
> dir1/a.o: dir1/a.h dir2/b.h
> dir2/b.o: dir2/b.h
>
> Que es un embole de mantener. Pero vos preguntaste
> como hacerlo solo con makefiles :)


Hmm, pero si te fijás en el paper que mandaste, ahí muestra una forma
mucho más simple y que no es así de embolante/imposible de mantener.
(Básicamente, usar includes en el Makefile)

> Más interesante que la solución es el problema. En
> esencia, el problema es que make tiene algunas cosas
> conceptualmente rotas, que se ven cuando empezas a


Es make el que está roto? El autor del paper que linkeás más abajo dice que no.

Citando,

'''
This paper presents a number of related problems,
and demonstrates that they are not inherent limita-
tions of make, as is commonly believed, but are
the result of presenting incorrect information to
make.
''' (pág. 13)

> partir un proyecto en directorios. En esencia, podés
> separar un proyecto en directorios, pero perdes alguna
> de estas dos cosas:
> * La capacidad de modularizar del mismo modo el
> proceso de build (haciendo varios makefiles)


Esto es justamente de lo que habla el paper. Dice, básicamente,
"Cuando hacés makes recursivos*, rompés el grafo dirigido acíclico que
describe las dependencias entre los archivos de tu proyecto. Esto
resulta en errores en el proceso de build."

* Los "makes recursivos" se dan cuando en un Makefile llamamos a make
en otro directorio. (bah, no hace falta que sea en otro directorio,
pero ese es el caso en gral.)

También dice (pero es mucho menos contundente en este punto), "Usando
make adecuadamente [con un sólo Makefile bien escrito, usándo las
técnicas que expone], podés mantener la misma modularización sin
romper el proceso de build, y no es ni complicado ni difícil de
mantener."

> * La capacidad de indicar dependencias entre
> archivos en distintos directorios.


Esto simplemente no es cierto. Lo que sí es cierto es que *si hacés
makes recursivos* (un makefile por cada subdirectorio del directorio
raíz de tu proyecto), *entonces* perdés esta capacidad. Por lo que
muestra el paper que pasaste, es muy fácil hacer esto con un sólo
Makefile en el raíz del proyecto sin que ese Makefile se transforme en
una bestia abominable. Lo que sí, algunas de las técnicas que expone
el paper usan features de GNU Make que pueden no estar en otros unices
(e.g. includes, evaluación inmediata de macros y VPATHs).

> Te insisto de nuevo que te fijes en SCons:
> http://scons.sourceforge.net/


Yo nunca probé SCons... la única experiencia que tuve con él fue con
un proyecto que lo usaba. En ese caso SCons no resolvía correctamente
la existencia de unas bibliotecas en mi sistema. Le otorgo el
beneficio de la duda pues es probable que ese proyecto haya estado
usándolo mal...

¿Tenés ganas de hacer elogio de sus bondades? Quizás convencés a alguien. :P

> Entre la documentación está este link que describe un
> poco mejor la esencia del problema que esbocé arriba:
> http://www.pcug.org.au/~millerp/rmch/recu-make-cons-harm.html


El paper está bueno, y es de lectura muy accesible, se los recomiendo
a todos. :-)

Saludos,
Cholo.

-- 
"I've got a clan of gingerbread men, here a man, there a man, lots of
gingerbread men; Take a couple if you wish, they're on the dish."
    -- Pink Floyd - Bike