Nos acercamos al final de la serie dedicada al terminal, y después de cinco capítulos de contenido bastante asequible, por fin nos metemos en harina. Así y todo, estoy convencido de que muchos de vosotros le perderéis el miedo al tema de la compilación tras ver el tutorial de hoy. Bueno, en realidad perderíais ese miedo al ver cualquier tutorial o entrada de blog o cualquier fuente de información donde aclaren los pasos de la compilación en Linux, que en realidad es un acto bastante sencillo de hacer a poco que nos organicemos y, sobre todo, recordemos que hay unas cuantas variantes en este asunto. La que os presento en el vídeo, aderezada con algunas alternativas, es la que se considera clásica, y representa un gran porcentaje de las posibilidades que os encontraréis por esos pagos de internet.
Los archivos que veis en la imagen superior son los típicos que nos encontraremos. Básicamente todos suelen tener el mismo tipo de información:
Cuál debemos elegir de los tres dependerá de la extensión del archivo comprimido. Y para ser transparentes, vamos a examinar qué significan esas letras que van detrás de la orden tar:
Por si acaso queréis estar completamente seguros, podéis hacer clic sobre el botón inferior que pone "aplicar permisos a los archivos contenidos". Toda precaución es poca...
No obstante con el método gráfico tenemos el mismo resultado sin tener que aprendernos de memoria los códigos, así que lo dejo a vuestra elección (y quizá usáis una distro muy rara que no incluye la opción de descomprimir al hacer clic derecho, ya sabéis que hay más distros que longanizas). Por cierto, en este enlace tenéis una buena guía sobre muchas de las posibilidades del programa tar en línea de comandos. Realmente potente, oiga.
Recuerdo que cuando empecé con esto de Linux, hace menos años de los que pensáis, una de mis primeras hazañas fue intentar compilar un programa de edición gráfica basado en Gimp llamado Cinepaint. Animado sobre todo por mi desconocimiento, comencé la tarea tirando de intuición, y leyendo el README del archivo comprimido (tardé en darme cuenta de que un archivo tar.gz es un archivo comprimido) fui haciendo paso por paso. Os lo creáis o no, lo conseguí. Eso sí, al no tener ni idea de que compilar un programa puede llevar tiempo de procesamiento, lo hice en mi fiel netbook, que por aquel entonces sufrió (y mucho) el proceso de aprendizaje sobre esta plataforma; la compilación duró alrededor de cuatro horas, sin contar el tiempo que tardé en instalar todos los paquetes de dependencias. Pero lo conseguí. Esta fue una de las cosas que creo me convencieron de que Linux molaba. Si yo podía hacerlo, es que Linux estaba bien pensado. Eso sí, debo confesar que jamás he conseguido volver a instalar Cinepaint, supongo que por alguna dependencia obsoleta. En cualquiera de los dos casos, son claras muestras de las dos condiciones que ponía al principio. Paciencia: si hay muchas dependencias y el programa es grande, la cosa puede llevar horas. Sentido común: cuanto más raro o antiguo sea un programa, más probabilidades hay de que la compilación sea o muy difícil o directamente imposible.
Hay otro problema colateral que puede dificultar la compilación: el hecho de que, nos guste o no, el lenguaje de la informática es el inglés. Aquí la solución es obvia: un cursillo acelerado si no conocéis el idioma previamente. En muy raras ocasiones me he encontrado con programas cuyas instrucciones estén escritas en la hispánica lengua. De hecho, en el vídeo os muestro el ejemplo de turpial, pulcramente explicado en castellano, pero que os prometo fue algo fruto de la más pura casualidad. No creo que en el fondo esto sea algo criticable; el inglés, nos guste o no, es la lengua franca planetaria y hay que aceptarlo como un hecho. Pero hay que reconocer que la cosa se vuelve más difícil si no nos manejamos mínimamente con el idioma de Shakespeare.
Sí y no. La mayoría de las veces no va a ser necesario hacerlo. Los programas precompilados, esto es, aquellos programas que ya han sido compilados por sus desarrolladores y comprimidos en paquetes autoinstalables (.deb, .rpm) son en la actualidad la manera más sencilla, cómoda y limpia de instalar un programa en nuestro sistema. Sólo en algunos casos podría ser conveniente la instalación desde el código fuente, sobre todo en algunos muy determinados en los que será beneficioso compilar con alguna opción "extra". En la siguiente imagen, por ejemplo, nos encontramos con estas opciones especiales para el programa Ufraw:
En algunas ocasiones estas opciones nos brindan nuevas o mejores funcionalidades que no vienen "por defecto" en el programa precompilado; en otras, y estas son las más importantes, una compilación adaptada puede ayudarnos a que un programa que nos daba problemas pueda funcionar correctamente en nuestra distribución. ¿Cómo sabremos cuándo es conveniente una cosa o la otra? He aquí otra de las cosas buenas que tiene Linux: tendréis que estudiar para averiguarlo. Los usuarios de Linux, que somos libres, tenemos en nuestra mano que todo funcione como debe. Para ello contamos con la, en general, buena y completa documentación de cada programa, con páginas y páginas web que dan la información que necesitamos... incluso hay algunos locos que se dedican a hacer tutoriales grabados en vídeo con el fin de echar una mano a los demás. Y esto, lejos de ser un defecto de Linux, es su principal virtud. Al convertirnos en corresponsables, nos da la oportunidad de aprender. Y conforme aprendemos, nos volvemos más autónomos, y podemos pasar a ayudar a otros. En otros sistemas la máxima es un poco diferente:
Por qué la compilación mola
En realidad la compilación ni mola ni deja de molar. Lo que de verdad está bien y resulta emocionante es lo que está en el fondo de este proceso: la posibilidad de instalar un programa en cualquier sistema que atienda a unos estándares, da igual cómo esté construido. Si tenemos las herramientas y conocimientos adecuados, contar con el código fuente garantiza que podremos ejecutar un programa. Esto que parece algo anodino en realidad constituye la magia y el milagro del Software Libre. Por que estos códigos fuentes almacenados en un simple tarball son libremente modificables si están, eso sí, bajo la correspondiente licencia que lo permita legalmente. El código fuente liberado significa progreso porque nos involucra a todos en el trabajo de mejora y desarrollo de los programas. Y encima poder utilizar de manera práctica el código fuente de un programa es una tarea sencilla. Son tres pasos, como indico en el vídeo. Que algo en realidad tan complejo se pueda hacer con un puñado de comandos es lo que hace que Linux sea, se pongan como se pongan, el sistema operativo más potente que existe. Más que nada porque el propio sistema operativo también es libre. El que opine lo contrario es idiota.Algunos consejos
No soy quién para dar consejos, que para algo tengo muy a gala no tener ni pajolera idea de programación, pero sí que puedo aportar algo de mi corta experiencia con estas cosas. Una idea que conviene tener en cuenta es echarle un vistazo al tarball que nos hayamos descargado. Examinando los archivos que contiene el fichero comprimido podremos hacernos una idea de las posibilidades y estrategias de compilación/instalación que deberemos seguir:
Los archivos que veis en la imagen superior son los típicos que nos encontraremos. Básicamente todos suelen tener el mismo tipo de información:
- Readme: este es de los importantes; es el que nos informa de cuáles son los pasos que tendremos que hacer, las dependencias necesarias y la estrategia concreta de compilación o instalación. también lo podréis encontrar con el nombre de LÉEME, en castellano.
- Manifest: Suele contener una descripción del programa, con sus funciones, historia de la aplicación, autores... A veces también aparece con el nombre de Authors.
- Copying: La licencia de uso. Es importante conservarla, por si algún pesado no toca las narices en algún caso improbable.
- Todo: "cosas por hacer"; nos cuenta en qué están trabajando los desarrolladores de cara a la próxima versión del programa.
- License: Parecido a Copying. Guardadlo, es lo más parecido a una factura que existe en el mundo GNU.
- Configure: Este es el más importante de todos. Si existe este fichero, es que efectivamente podemos compilar mediante el procedimiento típico. Y si no existe, entonces ya sabemos que no se compila de la misma manera. Toca localizar otros archivos: ejecutables (se distinguen por un icono característico), scripts de ejecución (con diferentes extensiones: .sh, .py, .run...), etc. En cualquier caso, el readme es nuestro amigo, nos indicará cuál es el camino que debemos de seguir.
tar xvf nombre_del_archivo.tar
tar xvfz nombre_del_archivo.tar.gz
tar xvfj nombre_del_archivo.tar.bz2
Cuál debemos elegir de los tres dependerá de la extensión del archivo comprimido. Y para ser transparentes, vamos a examinar qué significan esas letras que van detrás de la orden tar:
- x: (extract) le decimos a tar que se ponga a extraer archivos como si no hubiese un mañana.
- v: (verbose) le ordenamos a tar que nos vaya enseñando un listado de los archivos que va descomprimiendo. Esta orden es opcional, si no la ponemos tar descomprimirá "en silencio" y no tendremos información en pantalla sobre los archivos que se van descomprimiendo. No obstante su uso es obligatorio si hay alguien mirando que no tenga conocimientos de Linux: las líneas moviéndose a la velocidad de la luz en una pantalla de terminal siempre quedan muy bien y pensarán que somos unos hackers de quinto dan.
- f: (following) le decimos a tar que descomprima el archivo siguiente.
- z / j: (la z viene de zip, y la j supongo que de Jen0f0nte, agradezco el homenaje tardío pero merecido) El uso de una de estas dos letras dependerá de la extensión del archivo. z es para el método de compresión llamado gzip, con extensión .tar.gz, y j es para el método de compresión bzip2, con extensión .tar.bz2; si el .tar no tiene más extensiones, no ponemos nada, que tar (el programa, no la extensión) ya sabrá de qué va el asunto.
Por si acaso queréis estar completamente seguros, podéis hacer clic sobre el botón inferior que pone "aplicar permisos a los archivos contenidos". Toda precaución es poca...
No obstante con el método gráfico tenemos el mismo resultado sin tener que aprendernos de memoria los códigos, así que lo dejo a vuestra elección (y quizá usáis una distro muy rara que no incluye la opción de descomprimir al hacer clic derecho, ya sabéis que hay más distros que longanizas). Por cierto, en este enlace tenéis una buena guía sobre muchas de las posibilidades del programa tar en línea de comandos. Realmente potente, oiga.
El problema de las dependencias
Quizá sea este el único defecto de la instalación mediante código compilado. Según los casos, compilar un programa puede ser tan fácil como ejecutar los consabidos ./configure, make y make install, o tan agotador como construir un árbol de dependencias lleno de ramificaciones inextricables. En este sentido, conviene tomárselo con paciencia y con un poco sentido común.+-+gedit_345.png) |
| ¡Ajá! Si hay ./configure, la compilación es de las típicas |
Recuerdo que cuando empecé con esto de Linux, hace menos años de los que pensáis, una de mis primeras hazañas fue intentar compilar un programa de edición gráfica basado en Gimp llamado Cinepaint. Animado sobre todo por mi desconocimiento, comencé la tarea tirando de intuición, y leyendo el README del archivo comprimido (tardé en darme cuenta de que un archivo tar.gz es un archivo comprimido) fui haciendo paso por paso. Os lo creáis o no, lo conseguí. Eso sí, al no tener ni idea de que compilar un programa puede llevar tiempo de procesamiento, lo hice en mi fiel netbook, que por aquel entonces sufrió (y mucho) el proceso de aprendizaje sobre esta plataforma; la compilación duró alrededor de cuatro horas, sin contar el tiempo que tardé en instalar todos los paquetes de dependencias. Pero lo conseguí. Esta fue una de las cosas que creo me convencieron de que Linux molaba. Si yo podía hacerlo, es que Linux estaba bien pensado. Eso sí, debo confesar que jamás he conseguido volver a instalar Cinepaint, supongo que por alguna dependencia obsoleta. En cualquiera de los dos casos, son claras muestras de las dos condiciones que ponía al principio. Paciencia: si hay muchas dependencias y el programa es grande, la cosa puede llevar horas. Sentido común: cuanto más raro o antiguo sea un programa, más probabilidades hay de que la compilación sea o muy difícil o directamente imposible.
Hay otro problema colateral que puede dificultar la compilación: el hecho de que, nos guste o no, el lenguaje de la informática es el inglés. Aquí la solución es obvia: un cursillo acelerado si no conocéis el idioma previamente. En muy raras ocasiones me he encontrado con programas cuyas instrucciones estén escritas en la hispánica lengua. De hecho, en el vídeo os muestro el ejemplo de turpial, pulcramente explicado en castellano, pero que os prometo fue algo fruto de la más pura casualidad. No creo que en el fondo esto sea algo criticable; el inglés, nos guste o no, es la lengua franca planetaria y hay que aceptarlo como un hecho. Pero hay que reconocer que la cosa se vuelve más difícil si no nos manejamos mínimamente con el idioma de Shakespeare.
¿Merece la pena compilar aplicaciones?
Sí y no. La mayoría de las veces no va a ser necesario hacerlo. Los programas precompilados, esto es, aquellos programas que ya han sido compilados por sus desarrolladores y comprimidos en paquetes autoinstalables (.deb, .rpm) son en la actualidad la manera más sencilla, cómoda y limpia de instalar un programa en nuestro sistema. Sólo en algunos casos podría ser conveniente la instalación desde el código fuente, sobre todo en algunos muy determinados en los que será beneficioso compilar con alguna opción "extra". En la siguiente imagen, por ejemplo, nos encontramos con estas opciones especiales para el programa Ufraw:+-+gedit_346.png) |
| Opciones extra de compilación para Ufraw |
En algunas ocasiones estas opciones nos brindan nuevas o mejores funcionalidades que no vienen "por defecto" en el programa precompilado; en otras, y estas son las más importantes, una compilación adaptada puede ayudarnos a que un programa que nos daba problemas pueda funcionar correctamente en nuestra distribución. ¿Cómo sabremos cuándo es conveniente una cosa o la otra? He aquí otra de las cosas buenas que tiene Linux: tendréis que estudiar para averiguarlo. Los usuarios de Linux, que somos libres, tenemos en nuestra mano que todo funcione como debe. Para ello contamos con la, en general, buena y completa documentación de cada programa, con páginas y páginas web que dan la información que necesitamos... incluso hay algunos locos que se dedican a hacer tutoriales grabados en vídeo con el fin de echar una mano a los demás. Y esto, lejos de ser un defecto de Linux, es su principal virtud. Al convertirnos en corresponsables, nos da la oportunidad de aprender. Y conforme aprendemos, nos volvemos más autónomos, y podemos pasar a ayudar a otros. En otros sistemas la máxima es un poco diferente:
Si no funciona, tejodesfastidias. Tu paga y ya veremos.