Manual de introducción a la compilación

• Configuración
• Construcción
• Instalación
• Sistemas de construcción
• ¿Todo paquete tiene script de configuración?
• ¿Cómo puedo saber la secuencia a seguir para instalar?
• ¿Dónde instalar?
• Configure falla, ¿qué le ocurre?
• ¿Cómo puedo deducir el paquete que falta por los mensajes del configure?
• Compilando aplicaciones KDE
• Instalando bibliotecas compiladas desde código fuente
• ¿Cómo puedo hacer un icono en el escritorio de KDE?

A continuación hay un pequeño manual introductorio a la compilación de paquetes desde código fuente. Antes de nada, aclarar que esto debería ser un último recurso a utilizar en casos concretos. Antes de instalar desde código fuente:

* intenta siempre instalar paquetes empaquetados en un fichero rpm, preferiblemente de los repositorios de tu distribución utilizando urpmi.

* si no los encuentras, busca en cooker por una version de ese paquete en formato "bla-bla-12.34-56.src.rpm". Luego, creas un rpm a partir de ese "source rpm": rpmbuild --rebuild bla-bla-12.34-56.src.rpm

Si ninguna de las opciones anteriores funcionó... es hora de sacar las pócimas y sortilegios e instalar un paquete de código fuente. Muchos han muerto intentándolo, pero no sufras, con la ayuda de este pequeño manual de introducción espero que puedas sobrevivir para contar con orgullo a tus nietos como compilaste tal paquete.

Vamos con una pequeña explicación de ./configure, make y make install (que conste que no soy ningún erudito, así que puede que meta algún gambazo ;) ).

Configuración

El primer paso de dicha secuencia es la configuración del paquete. En esta etapa el paquete se prepara para su compilación configurando diversos parámetros del paquete (como lugar en donde instalar, dónde se encuentra determinada biblioteca, etc), comprobar que se cumplen las dependencias, etc.

Configure no es un programa como tal, sino que es un script, distinto para cada paquete. No obstante, pese a que cambia según el paquete, opciones como "--prefix" son algo genérico y suele estar presente en todos. Las opciones del configure, por lo general, puedes verlas mediante

./configure --help

(opción que tienen la mayoría de los scripts/programas de línea de comandos para saber cómo invocarlos).

Construcción

Una vez que el paquete está configurado, se pasa a su construcción. Cuando se trabaja con ficheros make, lo normal es que dichos ficheros sean creados por el script ./configure una vez termina exitosamente y dispone de toda la información para crear dichos ficheros.

Los ficheros make contienen una serie de instrucciones que serán ejecutadas por el programa make. Hay diversas versiones de make, y puede haber más de una instalada en el sistema, ya que algunos ficheros make sólo funcionan con versiones concretas del ejecutable make.

La construcción puede ir desde compilar el código fuente a generar documentación pasando, por ejemplo, por crear ficheros PNG a partir de ficheros en SVG. Pero, en general, lo que se hace al construir es compilar el código fuente.

Instalación

Una vez construido, ya se dispone de los ejecutables, bibliotecas, etc necesarios para utilizar el paquete. Pero aún no están en su sitio. Deben instalarse a su ubicación final. Para ello se ejecuta make install, que lo que hace es ejecutar make y decirle que utilice el conjunto de instrucciones marcadas como "install" en el fichero make.

Otra opción interesante es crear un rpm a partir de un paquete construido para ser instalado como cualquier otro fichero rpm. Tiene la ventaja de poder desinstalarse incluso en aquellos paquetes cuyo fichero make no tiene el objetivo uninstall (make uninstall). Puedes ver un interesante artículo de Sinner sobre este tema aquí: Construye tus propios paquetes (rpm, deb, tgz)

Hay que tener en cuenta que si se configura y construye un paquete en el directorio en que se quiere instalar... eso no sirve ;) (al menos en Mandriva, más sobre esto luego). La estructura de un paquete construido y la de un paquete instalado, por lo general, poco tienen que ver. Para no enrollarme mucho con esto... simplemente poner el ejemplo más sencillo: lo que en un paquete construido puede estar en el directorio src, en uno instalado puede estar en bin.

Sistemas de construcción

Y el último detalle sobre la secuencia ./configure, make y make install. No siempre se puede hacer así. Esa secuencia es la utilizada por programas que siguen el sistema de construcción GNU (artículo de la Wikipedia inglesa) que, aunque son la mayoría, no son todos.

Aunque tampoco es un problema muy importante. El motor de juegos Crystal Space por ejemplo creo recordar que para la construcción utiliza jam, por lo que habría que hacer ./configure, jam y jam install.

KDE, por su parte, para la construcción utiliza unsermake, pero desde el punto de vista del usuario eso es indiferente porque se ejecuta directamente con ./configure, make y make install (no sé cómo lo hace internamente, quizás alguna instrucción en el fichero make que a su vez ejecuta unsermake, pero no lo sé).

Así que como ves, el cambio de un sistema de construcción a otro no suele ser algo muy traumático ;)

¿Todo paquete tiene script de configuración?

Como ya se dijo, por lo general, los paquetes que uno se baja no llevan un fichero Makefile ya creado. Suelen llevar el Makefile.am y el Makefile.in, pero el Makefile (o equivalentes según el sistema de construcción) suele crearse una vez configurado el paquete.

Excepción a esta regla son algunos paquetes muy "sencillos", por ejemplo el módulo del kernel CDemu, que no tiene sistema de configuración, sino que utiliza ya un fichero Makefile de construcción directamente. Algunos de estos ficheros Makefile necesitan ser editados manualmente (lo que haría la configuración de forma automática), y otros están listos para construir sin necesidad de tocar nada. Todo depende del paquete.

Otro caso en el que no suele haber ni siquiera script de configuración es en los paquetes bajados directamente de un sistema de control de versión (artículo de Wikipedia española) como CVS o Subversion. No obstante, si compilar desde paquetes de código fuente suele ser el último recurso, éste ya se sale de las tablas ;) Sólo está recomendado para desarrolladores, beta-testers o gente muy, muy valiente ;)

¿Cómo puedo saber la secuencia a seguir para instalar?

Leyendo :) Incluso un usuario experimentado, que con un vistazo rápido a la estructura de los archivos del paquete podría deducir qué sistema de construcción necesita utilizar, lee ;)

Generalmente, en la propia página web del paquete tendrás documentación que te indica cómo puedes construirlo e instalarlo desde código fuente. Además, los paquetes suelen contener un archivo INSTALL con la información necesaria para realizar la construcción e instalación. También suelen contener un fichero README en el que puede aparecer dicha información.

¿Dónde instalar?

Tras esta introducción a la compilación, vamos con la cuestión del prefijo de instalación. Personalmente, recomiendo instalar utilizando el prefijo /usr/local, principalmente por costumbre personal. También hay quien recomienda, como Pacho, instalar en /opt.

Instalar en /usr no suele ser una buena idea, ya que sería mezclar aplicaciones gestionadas por urpmi con las compiladas manualmente.

Cabe mencionar que instalar el paquete bar en el prefijo /foo no quiere decir que el paquete acabe en /foo/bar, sino que terminará disperso por /foo/bin, /foo/lib, /foo/share/bar.

¿Y qué significa cada directorio? ¿Por qué tanta dispersión? Para eso, nada mejor que echarle un ojo a Filesystem Hierarchy Standard.

En el tema que nos ocupa ahora mismo,

/opt purpose

/opt is reserved for the installation of add-on application software packages.

A package to be installed in /opt must locate its static files in a separate /opt/ or /opt/ directory tree, where is a name that describes the software package and is the provider's LANANA registered name.

Por otra parte:

/usr/local

The /usr/local hierarchy is for use by the system administrator when installing software locally. It needs to be safe from being overwritten when the system software is updated.

Es por eso que recomiendo instalarlo en /usr/local.

No todas las distribuciones siguen el FHS al pide de la letra, y algunas incluso lo redefinen por completo, como por ejemplo GoboLinux.

Configure falla, ¿qué le ocurre?

Por lo general, la mayoría de programas dependen de alguna biblioteca externa. A la hora de compilar, el compilador tiene que saber cómo trabajar con dichas bibliotecas. Los paquetes cuyo sufijo es devel contienen dicha información.

Es decir, que cuando se necesita compilar algo que depende del paquete libfoo, tendrás que instalar el paquete libfoo-devel.

Configure, entre las comprobaciones que hace está el asegurarse de que el compilador tendrá a su disposición dichos paquetes de desarrollo.

Si es la primera vez que compilas, seguramente te falten bastantes paquetes devel de los que se irá quejando el configure. La cuestión es instalar los paquetes que faltan, re-ejecutar configure, instalar los siguientes paquetes de los que se queje... así hasta que te diga algo en plan "Good. Start make now" o una cosa similar, momento en que podrás empezar a compilar. Suerte ;)

¿Cómo puedo deducir el paquete que falta por los mensajes del configure?

Vamos con la dilucidación de paquetes según errores del configure. Esto, más que otra cosa... es un arte :P La experiencia es la mejor forma de saber qué paquete te pide ;) Pero vamos con un ejemplo real:

El mensaje de error era el siguiente:

checking for X... configure: error: Can't find X includes.
Please check your installation and add the correct paths!

Lo primero que nos dices es que está buscando "las X". Es decir, está intentando encontrar las dependencias que necesita para construir relacionadas con el servidor X11 utilizado en el sistema. Dicho servidor en Mandriva y, actualmente, la mayoría de distribuciones, es X.org.

Veamos ahora el error: "Can't find X includes." No encuentra los ficheros include (lo dejo en inglés porque la traducción al español no me suena nada bien :P ) para el servidor X. Los include son los ficheros que necesita el compilador para saber cómo trabajan las bibliotecas que necesita para compilar (dicho en "profano" ;) ).

Como comenté, los paquetes que contienen esos ficheros llevan el sufijo devel en su nombre. Ahora bien, de todos los devel, ¿cuál se necesita? El del servidor X, obviamente. Y dicho servidor X es X.org como ya se dijo.

Echemos un ojo con urpmq a la lista de paquetes disponibles que contengan xorg en su nombre. Hay unos cuántos, pero espera... lo que buscamos es una biblioteca (lo general es que las dependencias con includes sean de bibliotecas, y no de aplicaciones normales). Y los paquetes de bibliotecas tienen el prefijo "lib".

Así que busquemos de nuevo, pero esta vez los que contengan libxorg en su nombre:

Los siguientes paquetes contienen libxorg:
libxorg-x11
libxorg-x11-devel
libxorg-x11-static-devel

¡Ajá! El primero de ellos es la biblioteca como tal de X.org. El segundo es lo que andábamos buscando: el paquete que contiene la información para el compilador para saber cómo trabajar con la biblioteca.

¿Y el tercero? ¿Qué es eso de static devel? Bueno, el tercero es un paquete un tanto especial. Algunas aplicaciones necesitan compilarse de forma que en su ejecución, en lugar de acceder a la biblioteca que se encuentra en el sistema, la lleven ellos mismos ya en sus entrañas. Para ese tipo de aplicaciones son los paquetes static devel: cuando se necesita compilar con bibliotecas estáticas.

Lo normal es compilar con bibliotecas dinámicas, que es el segundo paquete como te dije. El tercero quizás debas instalarlo en alguna ocasión, pero no es muy común.

Compilando aplicaciones KDE

Este paso sólo debe hacerse la primera vez que compiles algo de KDE.

Crear el archivo /etc/kderc y añadir en él (todo ello como root, ya que está en /etc, y preferiblemente en consola ;) ) lo siguiente:

[Directories]
prefixes=/usr/local

Con esto lo que haces es que KDE, además de buscar las cosas en su directorio por defecto (/usr), busque también en el directorio /usr/local, de forma que puedes instalar cosas de KDE compiladas usando /usr/local como prefijo y funcionarán como si estuviesen en /usr (de hecho, creo que /usr/local tendría incluso prioridad sobre /usr)
Debes reiniciar KDE (salir y volver a entrar en tu sesión vaya) una vez modificado /etc/kderc para que coja los cambios.

Instalando bibliotecas compiladas desde código fuente

Antes de nada, dejar claro que instalar bibliotecas desde código fuente es algo muy poco recomendable (sí, menos incluso que instalar aplicaciones ;) ), ya que suelen ser piezas claves del sistema, por lo que es mejor utilizar las propias de la distribución, que ya están probadas y bien integradas.

En ocasiones muy concretas y específicas, no obstante, es necesario instalar una biblioteca desde código fuente por algún motivo. En ese caso, hay que tener en cuenta unas consideraciones adicionales.

Instalar una biblioteca desde código fuente suele ir seguido de instalar una aplicación desde código fuente que utiliza dicha biblioteca. Como recordarás, a la hora de compilar una aplicación se necesita cierta información sobre las bibliotecas de las que depende. Dicha información, por lo general, la provee dicha biblioteca de un modo u otro.

Actualmente, posiblemente la forma más cómoda para los desarrolladores (y por tanto, la que probablemente tenga una aplicación más amplia) para llevar a cabo esto es mediante pkg-config. De modo similar a make, pkg-config es un programa ejecutable instalado en el sistema que al invocarse lee información de un fichero para obtener la configuración que necesitará una aplicación para usar una biblioteca.

Cuando se instala una biblioteca, se instala con ella el fichero conteniendo dicha información. El problema es que pkg-config, por defecto, busca los ficheros en una serie de directorios en los que, como se explicó antes, no deberías instalar paquetes desde código fuente.

¿Qué hacer entonces para que encuentre los ficheros de configuración de las bibliotecas instaladas desde código fuente? Debe establecerse la variable del shell $PKG_CONFIG_PATH a los directorios adecuados. Podrías establecerla en el propio shell justo antes de configurar un paquete que dependiese de la biblioteca. Pero, ¿no sería más cómodo que se estableciese al arrancar el sistema automáticamente?

Para esto está el directorio /etc/profile.d/. Los scripts para el shell Bash o csh que se encuentren en dicho directorio se ejecutarán (a no ser que lo hayas deshabilitado explícitamente en el fichero /etc/profile) cuando se inicialice el shell. Así pues, habría que añadir los siguientes ficheros al directorio /etc/profile.d/:
Para Bash, pkg-config.sh:

# Set PKG_CONFIG_PATH for Bash shell
export PKG_CONFIG_PATH="$PKG_CONFIG_PATH:/usr/local/lib/pkgconfig/"


Para csh, pkg-config.csh:

# Set PKG_CONFIG_PATH for csh
setenv PKG_CONFIG_PATH "${PKG_CONFIG_PATH}:/usr/local/lib/pkgconfig/"

Por supuesto, si en lugar de utilizar el prefijo de instalación /usr/local utilizaste otro, debes reflejarlo en esos ficheros ;)

¿Cómo puedo hacer un icono en el escritorio de KDE?

De regalo, y para terminar, aquí está el procedimiento a seguir para hacer un icono en el escritorio de KDE a un ejecutable que utilice un icono específico:

-Botón derecho en el escritorio
-Crear nuevo->Enlace a aplicación...
-En la pestaña General, establecer como nombre el que se desee que muestre el icono.
-En la pestaña Aplicación, establecer como Comando la ruta completa al ejecutable (el botón Examinar... es muy majo ;) )

Con esto, ya tendríamos lo mismo que realizando el enlace con arrastrar y soltar. Ahora vamos a poner el icono específico.
-En la pestaña General, click sobre el icono
-Buscar el icono en la lista, o acotar la búsqueda mediante la barra de búsqueda, seleccionarlo y ¡voilá!

Esto último funcionaría si el programa fue instalado en un prefijo usado por KDE, que por defecto es /usr, y que puede ser ampliado con la información añadida en /etc/kderc.

Y hasta aquí este pequeño manual de introducción ;)