Desarrollando con GNU Autotools (Parte I)

Probablemente muchos desarrolladores habituados a IDEs de hoy día (Eclipse, Visual Studio…) coincidirán conmigo en que la forma de desarrollar utilizando software libre es cuanto menos extraña. Todos conocemos la típica compilación de un paquete de código o tarball en cualquier sistema unix: “./configure & make & make install”. Estos tres comandos parecen mágicamente usables pero a la vez extremadamente complejos en su interior. Los archivos Makefile y configure que vemos en la mayoría de los tarballs de código son habitualmente, cuanto menos, infernales. La razón es que estos archivos no han sido escritos a mano (como antiguamente) sino mediante un proceso automatizado.

Muchos conoceréis autotools, son herramientas de desarrollo mas abstractas que make y configure, finalmente con ellas obtenemos nuestros amados ./configure y Makefile. ¿Pero cuantos habéis desarrollado algo utilizando autotools? Yo no lo había hecho nunca, pero esta tarde me he dispuesto a aprender y hacer algunas pruebas.

¿Para quién está dirigido autotools? Algunas consideraciones previas:
- No es aplicable para el desarrollo en windows si no tienes cygwin.
- Está especialmente para desarrollar en los lenguajes C y C++ aunque en principio es independiente del lenguaje, Mono (la implementación libre de .net) por ejemplo utiliza autotools.
- No apto para la gente que odie montones de archivos autogenerados (aclocal.m4, config.h.in, Makefilem config.status, autom4te.cache , config.sub, stamp-h1,config.guess…)

¿Que herramientas/lenguajes/procesos tienes que controlar para desarrollar minimamente con autotools?

Autotools está compuesta de dos herramientas principales: Automake y Autoconf.
Su misión es autogenerar los mastodónticos Makefile y configure mediante scripts mas abstractos: Makefile.am y configure.ac.

1- Saber construir ficheros “configure.ac” y entender su lenguaje de script. Para tareas básicas es muy fácil y puedes inspirarte en los configure.ac básicos que hay en las referencias.
2- Saber construir ficheros “Makefile.am” y entender su lenguaje de script.

Objetivo: Construir un programa con autotools a partir de un único fichero fuente main.c

1.1 Creando fichero Makefile.am:
Se trata de un script de alto nivel, sus responsabilidades son definir que archivos serán generados, su tipo (programa, librería estática, librería dinámica, librería temporal…), a par tir de que archivos fuentes serán generados y que dependencias tiene cada uno. También forma parte de sus responsabilidades definir donde se instalarán cada uno de los archivos generados

#crearé un ejecutable que se localizará en la carpeta estandar bin llamado main
bin_PROGRAMS=main
# El código de main es en main.c
main_SOURCE=main.c

1.2 Creando fichero configure.ac:
Se trata de un script de alto nivel, sus responsabilidades son principalmente definir que aplicaciones son necesarias en este proyecto de desarrollo(Compilador, parseadores, linkadores…)  así como la comprobación de qué librerías y paquetes deben estar instalados en el sistema. También es responsabilidad de este script pedir al usuario todo tipo de parametrizaciones y metainformación para el proceso de construcción. Finalmente es el encargado de generar todos los Makefile.in a partir de todos los Makefile.am existentes en la estructura de directorios del proyecto.

#el programa lo llamaré miprograma y su versión será la 0.1
AC_INIT(miprograma,0.1)
#inicializa automake
AM_INIT_AUTOMAKE
#indicamos un requerimiento: programa compilador de C en esta maquina
AC_PROG_CC
#una vez chekeado lo anterior habrá que generar el fichero Makefile a partir de su Makefile.am a partir de su Makefile.in
AC_OUTPUT([Makefile])

1.3 Creando la estructura estandar de directorio raíz de desarrollo
Autotools nos obliga a tener la estrucutra de directorio raíz de desarrollo estándar, esto implica tener que crear una serie de ficheros de información para el usuario (Authors, Readme…). Algunos de ellos pueden ser autogenerados cuando invocamos el comando automake añadiendo el argumento –add-missing, el resto debemos crearlos manualmente.

geus@geuset:~/tutorial$  touch NEWS README AUTHORS ChangeLog
geus@geuset:~/tutorial$  ls
AUTHORS  ChangeLog  configure.ac  main.c  Makefile.am  NEWS  README
geus@geuset:~/tutorial$  aclocal
geus@geuset:~/tutorial$  autoconf
geus@geuset:~/tutorial$  automake –add-missing
configure.ac:2: installing `./install-sh’
configure.ac:2: installing `./missing’
Makefile.am: installing `./INSTALL’
Makefile.am: installing `./COPYING’
Makefile.am: installing `./depcomp’
geus@geuset:~/tutorial$  ls
aclocal.m4      ChangeLog      configure.ac  INSTALL     Makefile     missing
AUTHORS         config.status  COPYING       install-sh  Makefile.am  NEWS
autom4te.cache  configure      depcomp       main.c      Makefile.in  README

Observad que los tres comandos utilizados son típicamente agrupados en un ./autogen.sh. Por otra parte es interesante ver como se ha creado el archivo Makefile.in que será la fuente para la generación del archivo Makefile cuando ejecutemos la configuración del proyecto. Es interesante tener siempre presente quien generó cada archivo ya que un cambio en el origen requerirá una nueva generación del mismo. También encontramos varios archivos temporales que de momento no deberían importarnos.

1.4 Configuración y compilación
Ahora podemos aplicar nuestro clásico ./configure con todas sus opciones estándar.

geus@geuset:~/tutorial$ ./configure –prefix=’/opt/prueba’
checking for a BSD-compatible install… /usr/bin/install -c
checking whether build environment is sane… yes
checking for a thread-safe mkdir -p… /bin/mkdir -p
checking for gawk… no
checking for mawk… mawk
checking whether make sets $(MAKE)… yes
checking for gcc… gcc
checking for C compiler default output file name… a.out
checking whether the C compiler works… yes
checking whether we are cross compiling… no
checking for suffix of executables…
checking for suffix of object files… o
checking whether we are using the GNU C compiler… yes
checking whether gcc accepts -g… yes
checking for gcc option to accept ISO C89… none needed
checking for style of include used by make… GNU
checking dependency style of gcc… gcc3
configure: creating ./config.status
config.status: creating Makefile
config.status: executing depfiles commands

En este punto tenemos un archivo Makefile construido que podemos utilizar las reglas típicas: all, clean, install, uninstall… En este caso continuaremos el proceso de construcción estandar.

geus@geuset:~/tutorial$  make
gcc -DPACKAGE_NAME=\”miprograma\” -DPACKAGE_TARNAME=\”miprograma\” -DPACKAGE_VERSION=\”0.1\” -DPACKAGE_STRING=\”miprograma\ 0.1\” -DPACKAGE_BUGREPORT=\”\” -DPACKAGE=\”miprograma\” -DVERSION=\”0.1\” -I.     -g -O2 -MT main.o -MD -MP -MF .deps/main.Tpo -c -o main.o main.c
mv -f .deps/main.Tpo .deps/main.Po
gcc  -g -O2   -o main main.o

1.5 Instalación y prueba
geus@geuset:/Datos/Archivos/Proyectos/tutorial$ sudo make install
make[1]: Entering directory `/media/Datos/Archivos/Proyectos/tutorial’
test -z “/opt/prueba/bin” || /bin/mkdir -p “/opt/prueba/bin”
/usr/bin/install -c ‘main’ ‘/opt/prueba/bin/main’
make[1]: Nothing to be done for `install-data-am’.
make[1]: Leaving directory `/media/Datos/Archivos/Proyectos/tutorial’

geus@geuset:~/tutorial$ cd /opt/prueba
geus@geuset:/opt/prueba$ ls
bin
geus@geuset:/opt/prueba$ ./bin/main
Hello world
geus@geuset:/opt/prueba$

Resumen
1. Crear archivo configure.ac
2. Crear archivo Makefile.ac
3. Crear archivos de estructura estandar de directorio de desarrollo
4. Ejecutar comandos (aclocal,autoconf,automake)
5. Ejecutar build clásico: ./configure & make & make install

Proximos posts:
- Aplicar el proceso de construcción a todo un proyecto con una estructura recursiva de subdirectorios. Crear librerías estáticas y dinámicas redistribuibles.
- Comprobar paquetes instalados en el sistema durante el proceso de configuración y linkarlos en el proceso de construcción.

Referencias
Estas referencias son interesantes para comenzar desde cero.
http://www.openismus.com/documents/linux/automake/automake.shtml
http://www.delorie.com/gnu/docs/automake/automake_35.html
De esta última es interesante especialmente el chapter 9. Especificando claramente las diferencias para generar un programa ejecutable, una librería distribuible (sea dinámica o estática) y una libreria no distribuible (solo útil en el proceso para ser linkada con otro objeto distribuible)

También muy interesante el libro “Programming with gnu software” (no el de o’really). Nos muestra una visión completa del desarrollo software libre. En concreto los chapters 9, 10, 11 y 12 tratan sobre autotools.
www.lrde.epita.fr/~akim/gnuprog2.pdf

Mas profundidad y como referencia:
http://sources.redhat.com/autobook/autobook/autobook_toc.html#SEC_Contents

Firefox google-toolbar wordtranslator and ubuntu 64bits

Firefox google-toolbar word-translator doesn’t work in ubuntu hardy 64bits and other 64bits ubuntu versions.
How to solve this is a bit hidden in the internet. I had the same problem a year ago and I forgot it so I have had to find it again, so I’ll write this post for future occasions or to help other people.

How to solve this?

In firefox, go to the url “about:config” and add two new entries :

• google.toolbar.auto_translate -> true (insert it as boolean type)
• google.toolbar.autotranslate_to_lang -> es (insert it as string type)

Hope it helps to anybody.

Hacer de mi pc un router

El problema: en mi habitación de mi casa solo una roseta (que vaya al router), me he dejado el switch en el otro piso, quiero internet en mi portátil a toda velocidad, sin wifi, con cable.
El material: Un cable cruzado, una NIC vieja (eth1, la que ya estaba es eth0) que he encontrado en un cajón. Mi sobremesa (geus-server), mi portátil (geus-laptop).
El contexto: Actualmente estoy tras un router en una VPN (192.168.1.0/24). Mi puerta de enlace es (192.168.1.1) y geus-server es 192.168.1.35  con un Ubuntu-Linux (Si, si, ya sé no se debe dar información de este tipo sobre tu red priviada)

La idea: es construir otra subred(192.168.0.0/24) colocando eth1 en geus-server, la conecto con geus-laptop. En teoría con esto me puedo conectar a internet desde mi portátil, solo hace falta que geus-server enrute los paquetes.

Manos a la obra: Para eso tenemos el comando ip. Entre otras cosas este comando permite modificar la tabla de enrutamiento de nuestro pc para configurarlo como un router (también existe el comando route, pero que yo sepa es obsoleto)

1. Configurar la ip de la nueva NIC
   sudo ifconfig eth1 192.168.0.1
2. Indicar a geus-server donde está la subred 192.168.0.0/24 y como comunicarse por ella:
   
   sudo ip route add 192.168.0.0/24 dev eth1 src 192.168.0.1
   (la subred está por la interface eth1 y te debes identificar por esa interface como 192.168.0.1)
3. Indicar a geus-server que envíe al router las peticiones que vengan de la subred 192.168.0.0/24
   sudo ip route add 192.168.0 via 192.168.1.1 dev eth0 src 192.168.1.35
4. Finalmente comprobamos el estado de la tabla de rutas
   $ sudo ip route show
   192.168.0.0 via 192.168.1.1 dev eth0  src 192.168.1.35
   192.168.1.0/24 dev eth0  proto kernel  scope link  src 192.168.1.35
   192.168.0.0/24 dev eth1  scope link  src 192.168.0.1
   default via 192.168.1.1 dev eth0
5. Asegurarse de que ningún firewall u otro software esté interfiriendo en el proceso, en mi caso firestarter estaba molestando.
   

Algunas conclusiones:

Aunque me he llevado varias horas probando cosillas finalmente me he quedado sorprendido con la facilidad con la que puedes configurar redes y subredes. Aún es mas fácil con una aplicación de gnome, Firestarter, que hace de frontend de toda esta administración y con un simple wizzard puedes compartir una conexión de internet (que por supuesto es menos potente que manejar la tabla de enrutamiento, pero para este caso particular también hubiera funcionado).

En fin, con “ip” se pueden hacer infinidad de cosas mas, que quizá algún día pruebe, una de las que me parece interesante es utilizar dos NICs conectadas a diferentes proveedores de internet y realizar un balanceo de la carga por prioridades.

Saludos.

Frikada de mi fin de semana: una aplicación para gestión de bolsa

Este fin de semana he frikeado en bastantes cosas: el libro de la gsoc “the beautiful code”, rssando mucho, programando bastante…

Para uso personal he construido un programa para la gestión de mis acciones en bolsa usando .NET.

Hace poco son inversor (estoy probando a ver si realmente se puede ganar algo) y la verdad es que con tanta información no me aclaro si gano o pierdo dinero o si ganaría mas en algo mas seguro como un depósito a plazo fijo u algo similar: operaciones, impuestos, dividendos .. necesito una herramienta que me permita consultar de forma mas potente mi estado.

Mi banco me ofrece toda esta información. Sin embargo carece de un sistema de consultas potente, es difícil sacar conclusiones o realizar consultas que pueden ser estratégicas.

Se necesitan dos herramientas:

• Un modelo de datos con la historia de tus movimientos.
• Un suministro de información a tiempo real del estado de la bolsa.

Para lo primero se ha utilizado Linq to Sql y un sql server express, con un par de trucos he conseguido la información de mis movimientos sin tener que escribirlas a mano uno a uno…

Para lo segundo se ha utilizado la web de YahooTrends a base de peticiones web y tratamiento de texto (usando System.Net.WebClient y System.Text.Regularexpressions), con esto podemos sacar los datos a tiempo real del valor de las acciones, además de mas información interesante (gráficas, noticias, tendencias…)

Una vez montado esto se puede hacer todas las consultas que se quieran. Ya solo falta una pequeña interfaz gráfica donde ir poniendo las primeras consultas que sean interesantes y con el tiempo ir poniendo otras mas complejas.

Regards and happy stocking.

Like tortoise svn but in gnome

Tampoco digamos tanto . Sin embargo algo que es un hecho es que los usuarios de tortoise svn que conozco cuando trabajan en linux se sienten bastante incómodos. Tortoise svn tiene una ventaja respecto a sus competidores, se maneja desde el explorador de windows.

En linux no he encontrado clientes con tal característica. Sin embargo nautilus ofrece de forma sencilla extensiones en los menús contextuales: nautilus-scripts. Ya hay gente que se ha preocupado de hacer lo necesario para hacer un menú parecido al de tortoise svn:

sudo apt-get install nautilus-script-collection-svn

nautilus-script-manager enable Subversion

No obstante en muchos aspectos deja bastante que desear, es interesante para hacer operaciones sencillas rápidamente (updates, commit, reverts, rename…). Sin embargo para operaciones mas complejas (diffs, logs…) recomiendo SVN Workbench.

---

Not completely like tortoise svn. However is a fact that most of tortoise svn users when work in linux miss that tool. The main advantage of tortoise svn against their competence is that you can work in the windows explorer directly without open any form or window program.AFAIK linux does not have clients with those features. Nonetheless nautilus deliver a easy way to extend contextual menus: nautilus-scripts. There are some of that nautilus scripts to work with subversion:
sudo apt-get install nautilus-script-collection-svn

nautilus-script-manager enable Subversion

Nevertheless IMO this tool has a few of weakness, it is useful for simple operations like (update, commit, revert, rename…), for complex ones is better use another client: I recommend SVN Workbench.

Sshfs Hints

Cuando usamos un servidor ssh como almacenamiento remoto es interesante plantearse el uso de sshfs.
Sshfs es un sistema de archivos que nos permite montar en local carpetas remotas del servidor ssh, es decir poder usarlo como si fuera un disco duro local . Un par de caracteristicas interesantes son:

• Comunicaciones seguras ssh (por lo que te hace falta tener instalado en la máquina un servidor ssh, por ejemplo openssh)
• Implementación sobre FUSE (sistemas de archivos en el espacio de usuario: sshfs, ntfs-3g…).

Configuración en /etc/fstab

sshfs#remoteUser@remoteHost:/ /local/folder/where/mount    fuse   user,noauto,gid=myGroup,uid=myUser,umask=007    0    0

Opciones (repasando conceptos)

• noauto: Indica que el montado hay que hacerlo explícito y no ocurrirá en el bootup.
• user: indica que cualquier usuario puede montar la partición (nouser: requeriría ser root) (users: permitiría que cualquier usuario lo pudiera montar o desmontar, a diferencia de user que el que la monta la desmonta )
• gid y uid: ownership de los archivos. En los sistemas FUSE son especialmente importantes ya que habitualmente carecen de capacidades para cambiar permisos y ownership
• umask: mascara de permisos(inversa a chmod), por ejemplo 007 permite que el owner y el group puedan leer, ejecutar y escribir

Opinión
En mi opinión estar implementado con FUSE lo hace “mas lentillo”. Supongo que la decisión de haberlo implementado sobre FUSE es para poder utilizar las librerías ssh de usuario directamente y no tener que implementar ningún módulo para el kernel.

Mas info acerca de fstab:

http://www.tuquito.org.ar/tukipedia/index.php?title=Entendiendo_Fstab
http://www.informatik.uni-freiburg.de/~mader/FSTAB-Tuning.html

Google Summer of Code 2008: I have been accepted!

I am excited.

The goal is provide a linq binding for sqlite in a maintainable/scalable way, a suit of tests and enough documentation for understand the work in the future.

Linq project includes O/R mapper capabilities in a similar way that Hibernate or NHibernate does (though are some substantial differences) so like any O/R mapper there are a internal and generic core for dealing with databases and specific logic for each database engine(usually known as binding, provider or controller): postgreesql, mysql, oracle, ms sqlserver. My GSoC objective is do implement that specific functionality for the Sqlite database engine to the Mono Project’s Linq implementation .

Those of you that don’t know what is linq have to know that is a project for the .NET platform that include O/R mapper capabilities and extends some syntactic features in C# and Visual Basic programming that bring near that languages to the functional and declarative programming (lambda expressions, query expressions, extensions methods, query protections into anonymous struts… and others cool features specially in static typed programming languages)

The start point DBLinq. They that want know what’s that, go to: http://code.google.com/p/dblinq2007/

Also congratulations to Christian López Espinola and Rafael Vargas also accepted in GSoC 2008 in ArgoUML project and Minix respectively. They are good friends and job partners, congratulations again!

Regards.

Hola WordPress

Llevaba un año sin escribir nada y tengo que hacer algo para motivarme, por eso necesito un wordpress en mi propia casa, en mi servidor, que pueda controlar y personalizar. A partir de ahora este es mi blog. http://geus.wordpress.com queda descatalogado, aunque no descarto periodicas exportaciones de los datos de este servidor.

WordPress en casa te permite personalizar con gran cantidad de plugins tu blog. Mucho mas que podrias hacerlo en www.wordpress.com, eso sí, luego existen otros inconvenientes.

El primer trasteo ha terminado con la destrucción de mi primer mensaje (parecido a este) y que el pobre penyaskito había comentado.

Saludos.

Lo que rodea a LINQ

Ya tenemos LINQ hasta en la sopa. Un par de tips:

Al parecer se está trabajando en una implementación para LINQ orientada al procesamiento paralelo: PLINQ.

Evidentemente no todo es paralelizable, pero quizá en la mayoría de ocasiones los bucles lo son y por tanto las querys de LINQ también lo son, en esos casos sería interesante poderlo declarar de forma explícita.

Por lo que he visto sería algo muy sencillo, parecido a esto:

(from p in People
 join c in Customers
 on p.Name equals c.Name
 select new {p.Name, p.Age}).AsPararell();

Imaginad que People es una fuente que viene de un fichero XML y Customers viene de una base de datos, operaciones I/O que de forma intrínseca traen esperas de los hilos de ejecución, paralelizar ambas mejorará el rendimiento en la mayoría de ocasiones.

Otra que lleva mas tiempo es BLINQ: generación de vistas y controlador dado un modelo de datos. (Ojo! lo interesante es la Vista(páginas asp.net)) algo similar al Scaffold de Ruby on Rails.

Es increíble el camino que está tomando el equipo de c#, están siendo muy atrevidos y la verdad es que según mi opinión lo están haciendo muy bien, c# su aspecto hoy es más dinámico y declarativo.

De sobra es sabido que los lenguajes fuertemente tipados tienen muchísimas ventajas, dado su rigor son insuperables cuando nos encontramos con proyectos de gama media y alta en complejidad y tamaño.

Sin embargo los lenguajes dinámicos siempre han destacado por su altísima productividad (RAD) para tareas concretas en módulos pequeños y que no requieran mucha complejidad, mas hoy con lenguajes
tan potentes como Python, Ruby, Groovy(que es una gran promesa, pronto oiremos hablar de el hasta en la sopa, también sobre GRails)

Lo que es sorprendente es que hoy día se compare su agilidad y potencia sintáctica, su mayor virtud con LINQ, hoy día podemos encontrar en Internet comparativas de Ruby, Python, Groovy y LINQ!!!

Puede que c# sea un antes y un después en los lenguajes de programación.

America’s Cup: Simulador de seguimiento

El pasado Noviembre Microsoft tuvo negociaciones con Alcatel(Patrocinador externo de la America’s Cup)  con intención de promocionar su tercera generación de productos y tecnologías de desarrollo junto con Windows Vista.

Microsoft llevaba muchas suculentas ofertas, pero como llegaban tarde (empieza en junio) no podían ir con las manos vacías por lo que nos encargó que le hiciéramos una pequeña demostración para un simulador 3d para el seguimiento de las carreras en tiempo real, recogiendo datos por gps.

Nos pusimos manos a la obra y en una intensa semana y media conseguimos resultados bastante interesantes.

Lo que cabe destacar mas es la mezcla de técnicas y tecnologías que hicimos. Se trata de una aplicación Windows.Forms, con un control de Windows Presentation Foundation empotrado (barra lateral) y otro control Windows.Froms cuyo pintado funciona con DirectX9.0. Es interesante ver que algunas de ellas se consideran oficialmente incompatibles (WPF y DirectX)

Por supuesto los gráficos son mejorables, pero solo es cuestión de tiempo si el proyecto completo sale a delante. Utilizamos Jad Engine como base para realizar la aplicación, la experiencia fue reconfortante.

Otros aspectos que intentamos esforzarnos fueron:

Camaras en primera persona, movimientos suaves. Intefaces elegantes y con efectos llamativos, vídeos con streaming en tiempo real que le diera gran flexibilidad(carrera real, publicidad, comentaristas, documentales de la tripulación…).

En aplicaciónes 3D lo que primero suele llamar la atención son los gráficos estáticos (modelos, fondos etc..) pero la dinámica aunque pase mas desapercibida es imprescindible y normalmente de mayor dificultad que los gráficos estáticos.

No es trivial conseguir un movimiento realista dado una lista de coordenadas, no pueden seguir los puntos en linea recta, deben ser curvas, los barcos deben tener un movimiento de pandeo en las curvas mas cerradas, y deben ir mas rápido entre dos puntos mas separados ya que los tiempos dados se presuponen periódicos.

Para solucionarlo realizamos una implementación de las curvas de bezier, que era construida con la lista de coordenada, dicha curva nos suministraba en cada instante, la posición, la dirección y el pandeo que debía tener cada barco en cada instante de tiempo. Para calcular las rutas implementé un pequeño editor que posteriormente nos generaba un xml con la ruta lista para insertar en el simulador.

Saludos y Feliz Año.