Autotools(2): Integracíon de getttext con autotools para internacionalizar aplicaciones (intltool).

Cuando deceamos que nuestra aplicación esté disponible bajo varios idiomas tenemos varias opciones, una de ellas es el conjunto de funciones gettext (glibc-reference-manual). En este pos veremos como inttool se integra de manera natural a autotools(see Autotools(1))., gettext es quien extrae las cadenas para su traducción pero inttool extiende sus funcionalidades permitiendo:

• -Detectar las herramientas necesarias para la configuración y contrucción del proyecto.
• -Extraer las cadenas a traducir.
• -Mezclar las cadenas en la app final.

A partir de este punto nos basaremos en nuesto “hola mundo” inicial (git clone https://github.com/denisacostaq/EmbeLinux --branch hola-mundo, puedes probar ahora ejecutar autoscan en el directorio del proyecto y después cat configure.scan ), agregaremos el directorio po en la raiz de nustro proyecto, aquí irán hubicados 3 archivos esenciales.

1. POTFILES.in: Listado de archivos que contienen cadenas a traducir. Si se crea vacio ejecutando
   make update-po dentro del directorio po tendrás las cadenas marcadas a trducir.
2. POTFILES.skip: Listado de archivos que contienen cadenas traducibles pero aún se trabaja en ellos(los programadores) por lo que los traductores no deben desgatarse en ellos.
3. ChangeLog: Lleva un control de los cambios efectuados en el proceso i18n, 110n (para ver más detalles sobre esto revise un exelente artículo publicado por la señorita Milagros Alessandra en el número 1 de la revista HD).

Además de estos 3 archivos se hubican el archivo con todas las cadenas traducibles(*.pot) y los archivos con todas las cadenas traducidas en los diferentes idiomas(*.po).

Debemos cambiar nuestro archivo configure.ac de manera que quede como en nuestro hola mundo internacionalizado(por lo que ha cambiado a la verción 0.0.2) pero es recomendable que usando las piezas de la primera verción llegues hasta la segunda siguiendo los pasos desde para que entiendas bien todo por ti mismo. Una forma cómoda de ver los cambios es usando una herramienta difftool(ej:meld), los cambio son menores y los comento a continucaión:

• AC_PROG_INTLTOOL ( [ 0.50.2-2 ] ): Para que ./configure chequee que esta intltool en la verción especificada(como minimo).
• GETTEXT_PACKAGE: Esta variable es usada para nombrar el paquete.
• AC_SUBST: Publica la variable pasada como parámetro para ser usada de manera gloval en el proyecto(en cualquier Makefile.am se podrá aceder a su valor), en este caso es útil para po/Makefile.in.in.
• AC_DEFINE_UNQUOTED: Esta macro se usa para declarar sus “parámetros” en config.h(para este caso ya que así le nombramos en AM_CONFIG_HEADER), si lo escribieramos en “C” sería: #define GETTEXT_PACKAGE “hola−mundo” que de hecho se puede observar en config.h que este es su resultado.
• ALL_LINGUAS: Contendría los idiomas que tenemos disponibles.
• AM_GNU_GETTEXT: Verifica que tengamos disponible gettext en nuestro sistema, además de agregar algunas entradas en config.h de manera automática.

En el archivo Makefile.am se han efectuado cambios en 3 variable de las que solo es nueva CLEANFILES en la que ponemos archivos que queremos eliminar con “make clean”. En src/Makefile.am solo es nueva INCLUDES que especifica donde estaran las cadenas traducidas. EL archivo src/hello_world_i18n.h es usado para garantizar que nuestra aplicación “siempre” compile aunque no esté disponible el soporte para internacionalización, basicamente si está _ (str) se sustituye en tiempo de preprocesamiento por ( const char ∗) gettext ( str), si no está se sustituye por si misma, o sea no es el resultado de gettext, si no el mismo parámetro lo que se optiene.

En src/main.c los únicos cambios destacables son:

• setlocale (LC_ALL, “”); al pasarle “” nuesto progrma uasará el “locale” definido por el sistema.
• bindtextdomain ( GETTEXT_PACKAGE, PACKAGE_LOCALE_DIR ); :Aquí usamos el valor establecido en src/Makefile.am.
• bind_textdomain_codeset ( GETTEXT_PACKAGE, “UTF-8″ ); : Aquí decimos la codificaciín de caracteres que vamos a usar.
• textdomain ( GETTEXT_PACKAGE ); define el dominio o ámbito de traducciones, normalmente reducido al dominio del programa y que se encuentra definido en GET- TEXT_PACKAGE.

La secuencia de comandos se ha modificado ligeramente:

mkdir m4 ; aclocal -I m4

autoheader

glib-gettextize --copy --force

intltoolize --copy --force --automake

autoconf

automake --add-missing

En el directorio “po” falta determinar el contenido del archivo POTFILES.in. Para ello, dentro

de dicho directorio basta invocar el comando:

cd po ; touch POTFILES.in ; intltool-update --maintain ; cd ../

esto mostrará los archivos que tienen cadenas a traducir y que no se encuentran en el archivo POTFILES.in. Para facilitar el trabajo, también se genera un archivo llamado missing(puede ser añadido al final de POTFILES.in).

./configure

cd po

make update-po

cp hola-mundo.pot es.po (Para estos archivos puedes usar Gtranslatro como explican en HD)

cp hola-mundo.pot fr.po (El francés lo dejaré sin traducir para que compruebes que la aplicación se ejecuta lo que solo en inglés)

cd ../

Traducir con Gtranslator(recomendación). Finalmente, tras ejecuta make dist, se tendrá la versión 0.2 del programa hola-mundo.

NOTA:

Para probar el prgrama debes tener los “locales” instalados (apt-get install locales-all), además la variable de entorno en el idioma que quieres, ej: export LANG=”es_ES.UTF-8″, deberás tener en cuenta que para este caso deberás instalar el progrmaa (sudo make install) por el lugar donde se ha especificado buscar los *.mo además debes establecer la codificacion de caracteres ej:UTF-8, si usas Gtranslator esto parecería tribial pero es muy importante. Por último la descarga de este ejemplo para que te guies y no te suene ambiuguo lo que he explicado, una tecnica puede ser usr una herramienta diff si ya habias entendido bien el ejmplo anterior.

git clone https://github.com/denisacostaq/EmbeLinux --branch hello-intltool

Autotools(1). Hola mundo a la autotools.

En lo que sique(incluido este como el primero) estaré publicando una serie de posts relacionados con la creación y configuración de proyectos basados en el grupo de herramientas de autotools(antes es aconsejable revisar el directorio /usr/share/doc/gnu-standards, de este no existir ejecuta apt-get install gnu-standards y además ver también este enlace a wikipedia) y algunas otras que se le integran muy bien, además mencionar que me basaré en los lenguajes C/C++ pero que bien se adapta a otro tipo de lenguajes como son C, C++, Java, Python, Fortran, Yacc, awk, etc.

Primero que todo veamos la estructura básica de un proyecto, los directorios y archivos principales que lo componen y después veremos como editamos estos últimos para lograr un proyecto muy básico, nuetro “hola mundo”.

Estructura básica:

Escojemos un directorio en el cual relizaremos nuestro trabajo y ejecutamos la siguiente secuencia de comandos para crear las bases del proyecto.

mkdir -p hola_mundo/src
cd hola_mundo/
touch Makefile.am configure.ac src/Makefile.am src/hello-world.c NEWS AUTHORS ChangeLog README MAINTAINERS HACKING VERSION THANKS TODO

Ejecutando el comando tree -v(man tree) ya visualizamos la estructura actual del proyecto (Fig 1) donde tenemos los archivos principales de información, (compuesto por 2 grupos, los obligatorios Fig 2 (aquí faltan COPYING e INSTALL lo que no los pondré ya que autotools te propone los correspondientes que deberás editar para adptarlo a las necesidades de tu proyecto) y los opcionales (Fig 3)), los archivos inherentes a las herramientas de autotools también llamados de configuración (Fig 4), y por su puesto los archivos/directorios donde estará el código fuente(en este caso solo uno).

Como contenido de estos archivos (los de información) se tiene una explicación sobre si mismos que se puede ver en un link que dejo al final con un ejemplo.

Edición de los archivos de configuración de autotools:

#configure.ac
AC_PREREQ([2.69])
AC_INIT([hola-mundo],[0.0.0], [denisacostaq@gmail.com], [hola_mundo], [blogspoot.com/embelinux])
AC_CONFIG_HEADERS([config.h])
AM_INIT_AUTOMAKE([1.10.1])
AC_PROG_CC
AC_OUTPUT([Makefile src/Makefile])

Comentaré superficialmente el contenido de este archivo, para una información más detallada ver /usr/share/doc/autoconf-doc/ (apt-get install autoconf-doc), este archivo se escribe en M4.

- AC_PREREQ advierte sobre la verción mínima de autoconf con que debe contar tu sistema (autoconf –version, para saber que valor poner en tu caso).

- AC_INIT tiene como parámetros el paquete, la verción, el e-mail de reporte de bugs, el nombre de empaquetamiento y la url del proyecto en ese orden y no siendo obligatorios todos estos parámetros.

- AC_CONFIG_HEADERS dice donde poner el archivo config.h(que puede tener otro nombre) el cual puede ser usado en el código de nuestro proyecto.

- AM_INIT_AUTOMAKE automake y especificamos que verción (automake –version). Se pueden escribir macros para automake, estas comienzan con el prefijo AM_ .

- AC_PROG_CC especificamos que usaremos el compilador de c y se le pudiera pasar un lista de comprobación, sino la pasamos autoconf comprueba usando una que tiene internamente.

- AC_OUTPUT especificamos los lugares en que queremos un Makefile(también se pueden obtener otros ficheros) como salida.

#Makefile.am
SUBDIRS = src
EXTRA_DIST =  README THANKS TODO HACKING MAINTAINERS

Para este archivo se puede leer el manual GNU Automake.

- SUBDIRS especifica los directorios por los que se debe mover make, es aproximadamente el orden que sequirá el “topological sort”.

- EXTRA_DIST es para incluir en el empaquetado archivos que no son indispensables en el proyecto.

#src/Makefile.am
bin_PROGRAMS = hola-mundo
hola_mundo_SOURCES = hello-world.c

En la variable bin_PROGRAMS especificamos el o los programas binarios que se van a crear. Después como muestra hello_world_SOURCES especificamos el código fuente a partir del cual se creará cada binario fijandote en tranformar el nombre del binario a su forma canónica, ej:hola-mundo -> hola_mundo y agregandole el sufijo _SOURCES.

Una vez editados estos archivos de configuración de proyecto ponemos el código, ej: printf (“hello world\n”); y por último coenzamos a invocar a las herramientas de autoconstrucción.

aclocal
autoheader
autoconf
automake -a (con la opcion -a no pone el archivo COPYING(enlace a /usr/share/automake-1.13/COPYING) e INSTALL(enlace a /usr/share/automake-1.13/INSTALL) como ya había mencionado)
./configure (en este punto se chequea si nuesto sistema está preparado para compilar el programa, por ejemplo desintala el compilador y verás lo que sucede).
make (ya podemos ejecutar nuestro programa que se llama hello_world y está en src).

La llamada a aclocal busca todas las macros m4 en todos los archivos *.m4 en el directorio donde se ejecuta y finalmente en configure.ac poniendolas todas juntas en el archivo aclocal.m4 que genera. El comando autoheader crea el archivo.h.in, autoconf es el responsable de crear el archivo(scrip) configure, automake genera los archivos Makefile.in ,y por ultimo ./configure es quien genera los Makefile a partir de Makefile.in y config.h a partir de config.h.in. A modo de resumen, se muestra en el siguiente diagrama el flujo del funcionamiento de las herramientas (Fig 5).

Fig 5

Adicionalmente podemos ejecutar como root make install que instala nuestro programa en el sistema, por defecto en /usr/local, podemos modificar esto volviendo a ejecutar ./configure pero esta vez con el parametro –prefix=PATH. También podemos ejecutar make dist y nos empaqueta el proyecto.
Como nota adicional comentar que debes tener todas estas herramientas en tu sistema para trabajar con autotools pero una vez que tengas el empaquetado solo necesitas los compiladores, bibliotecas, frameworks y todo de lo que dependa tu programa para compilarse pero no las herramientas con las cuales creates el paquete, o sea ya podrás ejecutar el clásico (./configure ; make ; sudo make install).

git clone https://github.com/denisacostaq/EmbeLinux --branch hola-mundo

Entendiendo la escencia de las bibliotecas mediante ejemplos de su creación y utilización.

Como ejemplo tomaremos la creación de una biblioteca para cálculos matemáticos, primero la haremos y usaremos estática y después compartida.

Biblioteca estática:

En una biblioteca estática tenemos una serie de procedimientos que son comunes pero cada programa que compilemos a partir de ella incluirá los archivos de los que use cualquier cosa dentro de su propio código atentando contra el tamaño del archivo binario final, no será necesario tener la biblioteca en el entorno en que va a correr el programa.

//plus.c
int plus (int sum1, int sum2)
{ 
    return (sum1 + sum2); 
}

//mult.c
int mult (int fact1, int fact2)
{
    return (fact1 * fact2);
} 

Para obtener el código objeto de estas dos funciones y/o archivos ejecutamos: gcc plus.c mult.c -c, con la opción -c le decimos a gcc que compile o ensamble nuestro código pero que no lo elnace (gcc se refiere a GNU Collection Compilers y/o a GNU C Compiler, pero en este último caso aclarar que no es en realidad gcc quien compila sino que es más bién un driver, o sea encarga a otros programas a hacer el trabajo). Para crear la bibliteca ejecutamos ar -r libmat.a plus.o mult.o, con esto libmat.a queda lista para ser usada como una biblioteca estática (rm *.o *.c).

//main .c
#include <stdio.h>
int plus (int, int);
int mult (int, int);
int main (int argc, char *argv[])
{
    int val1 = 2;
    int val2 = 5;
    printf (“%d + %d = %d\n”, val1, val2, plus (val1, val2));
    printf (“%d * %d = %d\n”, val1, val2, mult (val1, val2));
    return 0;
}
gcc main.c -lmat -o program (produce el siguiente error)
/usr/bin/ld: cannot find -lmat
collect2: error: ld returned 1 exit status 

Ahora ejecutamos gcc main.c libmat.a -o program que sí compila correctamente pero le estamos pasando la ruta de la lib de forma explícita, la manera elegante sería diciendole a gcc enlazate a mat(-lmat) para que él solo la busque pero no lo hemos conseguido porque el enlazador(ld) ha buscado en los directorios que tiene por defecto normalmente(/lib y /usr/lib más cat /etc/ld.so.conf.d/*) así que podemos agregar nustro directorio actual a las rutas de búsqueda con gcc main.c -L. -lmat -o program. Una forma más elegante de compilar es usando la variable de entorno LIBRARY_PATH, que sería así:

export LIBRARY_PATH=$LIBRARY_PATH:.
gcc main.c -lmat -o program

Además para ver lo que decía sobre que gcc es un driver podrias ejecutar gcc -### -lmat main.c -o program con lo que gcc te dice lo que haría si le quitas -### pero no lo hace.

Biblioteca compartida:

A diferencia de una biblioteca estática los programas que se compilan con bibliotecas compartidas (shared object, extención .so) no incluyen el código de estas dentro de sí, sino información de con que lib ha sido enlazado el programa de manera que cuando el programa se va a ejecutar el linkeador (ld-linux, no el que se usa para compilar) determina de qué bibliotecas depende nuestro programa para estar en RAM y de faltar alguna la carga, por ejemplo para el programa que habiamos compilado hasta ahora podemos saber de que depende usando ldd program, deberás notar que no depende de libmat.

Para crear una biblioteca comartida solo tenemos que especificarle esto a gcc con shared, usando todo el codigo que hasta ahora teniamos solo cambiaremos la manera en que creamos la lib y el programa y veremos el impacto:

gcc -c -fPIC mult.c plus.c
gcc -shared mult.o plus.o -o libmat.so
gcc main.c -lmat -o program (que tendrás un error, así que resuelvelo...  )

./prgram (te generará el siguiente error, ./program: error while loading shared libraries: libmat.so: cannot open shared object file: No such file or directory, si ejecutamos ldd program verás que a diferencia de el caso pasado este si depende de libmat y que además “not found”, para resolver esto tenemos que agregar como ruta de busqueda al elnlazador ld-linux(no el de compilar insisto), la ruta donde esté nuestra lib o mejor una solución más pacífica export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:. , con lo que puedes volver a ejecutar ldd para ver el cambio y además ya puedes ejecutar a ./program).

Bibliotecas dinámicas:

En este punto solo mencianaré que las bibliotecas dinámicas son una “forma” de las bibliotecas compartidas la diferencia es que en ahora el SO no autodetecta las bibliotecas de que depende el programa y las carga de forma automática, es el programador quien tiene esta responsabilidad, básicamente se cargan bajo demanda, tiene la ventaja de que la aplicación se carga en RAM más rápidamente y el inconveniente de que es el programador quien tiene la responsabilidad de hacer entonces ese trabajo, pudiera ser por ejemplo usando la lib ltdl que cuenta con funciones como dlopen.

En algún que otro post relacionado con autotools+libtool veremos como los humanOS hacemos esto, ya que hasta ahora solo vimos el método de los  “dinosauriOS” .

Domótica.

Fig 1.

 “La tecnología aplicada al hogar”(Fig 1), conocida como Domótica, integra  automatización, informática y nuevas tecnologías de comunicación; todas ellas dirigidas a mejorar la comodidad, la seguridad y, en definitiva, el bienestar dentro de los hogares. Esta contribuye principalmente  en aspectos cotidianos como: iluminación, climatización, seguridad, comunicación, etc.

Tal vez por error, es usual que algunas personas usen indistintamente otros términos en lugar de Domótica, ejemplos de esto son; “Hogar Inteligente” (término que se empleaba antes de surgir la Domótica, el término “Hogar Inteligente” suele ser más interpretado por las personas como la soluciones futuristas que como las novedades tecnológicas del momento), “Hogar Digital” (ya que es, gracias a la digitalización, que son posibles los nuevos equipos y/o servicios, aunque este está más estrechamente relacionado con las telecomunicaciones), “Inmótica”(que hace referencia a la coordinación y gestión de las instalaciones con que se equipan las edificaciones, así  como a su capacidad de comunicación, regulación y control, aunque “Inmótica” es de uso común, todavía no ha sido recogido por el diccionario de la Real Academia. Mientras la palabra Domótica se aplica al hogar, por Inmótica se entiende la incorporación de sistemas de gestión técnica automatizada a las instalaciones del sector terciario como son plantas industriales, hoteles, hospitales, aeropuertos, edificios de oficinas, parques tecnológicos, grandes superficies, universidades, instalaciones comunitarias en edificios de viviendas, etc. En realidad, los sistemas y aplicaciones Inmóticas son muy similares a los de la Domótica y, por ello, a menudo se emplea el concepto de sistemas Domóticos referidos también a este sector). La palabra Domótica tiene varios significados, según el diccionario de la Real Academia es “el conjunto de sistemas que automatizan las diferentes instalaciones de una vivienda”, pero se debe tener en cuenta que esto está en continuo cambio y bajo constantes discuciones y aunque todos estos son términos diferentes se encuentran estrechamente relacionados. Además, la Domótica no es aplicada solo a los hogares, también puede aplicarse a una oficina por citar un ejemplo.

Ya presentadas las diferencias entre cada uno de cada uno de estos términos tomaremos todo esto como una sola idea y lo trataremos más apmpliamente usando solo la palabra Domótica. Hoy no concebimos una vivienda que no tenga a gua corriente o electricidad, así mismo tal vez algún “día” podriamos no concebir una vivienda que no esté aunque sea minimamente “Domotizada”, el principal problema que ha afrontado la Domótica es que muy pocas personas han estado de acuerdo con incurrir en los costes adicionales pero el abaratamiento de las tecnologias ha hecho que ese “día” se parezca cada vez más al de hoy. En los últimos años el desarrollo vertiginoso de la ciencia y tecnología a traido con sigo un impacto directo en toda nuestra vida cotidiana, ya sea donde recidimos, donde trabajamos, o donde nos recreamos, de una forma u otra donde quiera que estés coincidirás en esto, te encontrarás con que la Domótica es algo de futuro pero en algún grado ya está presente en nuetra vida diaria. La aplicacion de la Domótica depende de las necesidades particulares de cada usuario final, pero de manera general el interés por la Domótica es una realidad palpable en la sociedad. Según los expertos, la infraestructura básica para domotizar una vivienda, sólo encarece el precio entre un 1-2 % de media; algo ínfimo si se pondera lo mucho que mejora el atractivo de cara al público.

Pero… ¿Qué significa vivir en un hogar digital y conectado?:
Algunas de las ventajas de vivir en un hogar digital y conectado, se ven en la siguiente imagen (Fig 2).

Fig 2. Aplicaciones de la Domótica.

Fig 3. Terminal de monitoreo/control

La terminal central(en caso de los sistemas con arquitectura centralizada según su tipología ver Fig 5 y el libro que aparece al final en “NOTA:” para más detalles) de supervición/control puede estar fija en un lugar de la casa(Fig 3-5), en una PC del propietario de la casa, en un servidor remoto accesible via internet, en un teléfono movil, en una agencia privada de seguridad(Fig 4), etc.

Fig 4. Agencia privada de seguridad.

Fig . Sistema de supervivió/control centralizado.

Como es de suponer en todo este sistema intervienen una serie de sensores(de radioondas, vibraciones, temperatura, presión, etc), actuadores (acciones de control para cierre de válvulas, desconección de equipos, activación de alarmas, etc), y equipos de uso domésticos que necesitan comunicarse entre ellos y con el exterior. La siquiente imagen muestra una red de Domótica cuyo componente principal (para esta topología) es la pasarela residencial que es la que media en la comunicación entre todos los equipos y el exterior.

Fig 6. HAN (Home Area Network).

Bibliografía:
Domótica. Edificios inteligentes. Ediciones Copyright. Madrid.(2004)
Domótica y hogar digital. Editorial Thomson-Paraninfo. Madrid.(2004)
Domótica e inmótica. Edificios inteligentes. Editorial Ra-Ma. Madrid.(2005)

NOTA:

Este post se basa (intenta ser un resumen de los conceptos más básicos) en una exelente publicación lanzada en España (La Domótica como Solución de Futuro. Guía descargable en formato pdf desde la sección de publicaciones de la página web), guía, en cuya elaboración han intervenido profesionales con una amplia experiencia en este campo, se abordan distintos temas, de una manera sencilla pero a la vez rigurosa, en algunos casos con ejemplos prácticos de cómo se puede llevar a la práctica las soluciones que se van comentando. Además la bibliografía mencionada aparce en esta y ha sido consultada ligeramente.