TrixX's Journal: Second systems (cont'd)

Un problema de postear tan irregularmente acá es que junto cosas para escribir, tomo nota mental, pasa el tiempo, y después me olvido. El árticulo pasado (Second Systems) lo había planeado hace mucho, pero tarde tanto en escribirlo que me olvidé uno de los ejemplos:

Scons: Esta es una segunda generación de software para hacer software building, o en realidad, el problema más general de resolver dependencias cuando se tiene un conjunto complicado de archivos generados a partir de más archivos. Todo el mundo conoce el sistema clásico para hacer esto, que es el "make" de UNIX. Hay un par de variantes más dando vueltas por ahí, pero la idea en todos es parecida. Muchos de los problemas de make son conocidos, tanto que hay docenas de parches encima de make para hacerlo funcionar, desde shell scripts caseros que generan Makefiles hasta cosas como Imake o automake.

Scons encara el problema de una forma un poquito distinta, pero creo que más práctica. Por empezar, uno de los problemas de make es que no maneja de muy buena forma proyectos con los archivos en un árbol de directorios (es decir, casi cualquier proyecto no trivial). Existen formas de tener un Makefile por directorio, e invocar recursivamente, pero son complejas de describir, y algunas cosas son imposibles (como indicar dependencias entre partes en distintas ramas del árbol). Esto hace que el building haga más cosas de las que se debe, y impide paralelismo. Scons maneja todo el árbol junto, y las dependencias cruzadas entre directorios son igual de simples que una dependencia común (en ese sentido es una generalización similar a la que va de CVS a SVN, pasar de manejar entidades sueltas dentro de un árbol a que el árbol sea una entidad). Se pueden especificar pedazos del proyecto en archivos en las subramas del árbol, para modularizar, pero después la herramienta trabaja analizando todo el árbol. En ese sentido y es bastante más fuerte que make.

El otro punto fuerte es la notación. Los procesos de build suelen tener muchas partes repetitivas con alguna variante. Para solucionar eso make tiene varios sistemas de generalizar reglas, o usar wildcards para indicar conjuntos grandes. En mi experiencia, incluso cuando está trabajando concientemente para que las cosas sean fáciles de hacer con make, esas generalizaciones no alcanzan. Con lo cual uno empieza a generar pedazos de Makefiles con otros programas, e incluirlas, o a copiar y pegar pedazos, o hacks similares. Scons tiene un lenguaje mucho más fuerte para describir estas cosas, tan fuerte que es Turing completo. El lenguaje se llama Python. Lo que también es una buena idea, porque no hizo falta aprender algo más. Para casos simples, la notación es tan compacta como un Makefile, para casos complicados, poder usar un ciclo o una comprensión de listas para generar un montón de nombres de archivos, o relaciones entre archivos fuente y objeto es muy práctico. Ojo, que no se malentienda que uno programa el build en python; lo que se hace es un script python que llaman a ciertas funciones predefinindas por scons que indican el arbol de dependencias, y las reglas de construccion, y despues de correr eso scons se encarga de analizar que partes hace falta regenerar (en base a fechas, checksums, y lo que pidió el usuario), y trabaja con eso. Es simple como un Makefile, pero permite hacer cosas complicadas cuando la tarea lo demanda.

Otra ventaja de que use python es que es facil programar extensiones para compilar distintas cosas a las predeterminadas. Además que cada extensión es un poco más inteligente que las reglas equivalentes de make. Por ejemplo, las reglitas de compilación de C y C++ saben fijarse los #includes y generar las dependencias que haga falta, no hace falta agregar un hack especial con gcc -MM generando un fragmento de Makefile que después es incluido.

Es una linda herramienta para los que usamos compiladores. He jugado con esto un poquito en programas en C, Eiffel, y cosas bastante custom (bulk image processing/conversion), se ha portado bastante bien. Tengo una charlita pendiente de esto en grulic.