Cuando empecé a investigar sobre las herramientas de desarrollo para Gnome me topé con el nombre de Anjuta varias veces. Anjuta es el IDE oficial del proyecto Gnome, ofrece un soporte sólido para el desarollo de programas GTK mediante los lenguajes de programación C y sus bindings para C++, Java, JavaScript y Vala.
La verdad es que el aspecto de la herramienta es bueno, incluye hasta un diseñador de interfaces WYSIWYG, pero receloso como soy de duplicar el conocimiento, me mostraba reticente a tener que aprender a usar una nuevo entorno de desarollo. Por ello y antes de ponerme manos a la obra, me propuse investigar si existía alguna forma de usar una herramienta que era por mí de sobra conocida: el IDE Eclipse.
Eclipse era originalmente un IDE destinado principalmente al desarrollo de aplicaciones Java, pero con el paso del tiempo fue ganando soporte para otros idiomas a través de plugins y builds específicos. Para C/C++ en particular, existe el plugin CDT, que añade soporte básico para compilación, enlazado, debugging, resaltado y autocompletado para este lenguaje. Configurar CDT y compilar usando la librería estándar de C/C++ es bastante fácil, sin embargo no se puede decir lo mismo del proceso para añadir soporte a librerías externas/no estándar como GTK, sobre todo para un novato como yo. La información que existe en internet sobre el tema es difusa y en muchos aspectos inexacta, y la interfaz de configuración de Eclipse no ayuda demasiado.
Es por ello que he decidido redactar este tutorial paso a paso sobre como configurar Eclipse para desarrollar en C++/GTK. No soy un experto, así que agradeceré cualquier corrección o experiencia que pueda añadir exactitud al proceso.
El punto de partida
Parto de una distribución Linux-Fedora 16 de 64 bits, con Eclipse para Java instalado. Las instrucciones para la instalación de paquetes serán las propias para este sistema operativo, así que tendrás que buscar el nombre del paquete correspondiente si usas otro. Si añades los comandos de tu distribución en los comentarios para instalar cada uno de los paquetes que aparecen en este tutorial gustoso los añadiré junto a los de Fedora.
Instalando soporte para C++/GTK
Primero, tenemos que instalar el compilador de C++. Para Fedora, podemos usar el comando de consola:
yum instal gcc-c++
Las librería GTK, así como las librerías de Gnome fueron diseñadas para C99, lo que significa el soporte para otros lenguajes se hace mediante bindings. En particular, el binding de GTK para C++ se llama gtkmm. En principio, instalar gtkmm debería ser suficiente para instalar como dependencia las librerías necesarias para desarrollar en GTK. El comando para Fedora sería:
yum install gtkmm30
Instalamos también las librerías de desarollo de gtkmm. Técnicamente, instalar las librerías de desarrollo debería resolver las dependencias necesarias para instalar gtkmm.
yum install gtkmm30-devel
Técnicamente, el sistema está listo para compilar.
Instalando Eclipse y el plugin CDT
Hay que instalar el plugin CDT para añadir soporte para C/C++ a eclipse. El comando en Fedora sería
yum install eclipse-cdt
Si no tienes instalado Eclipse, la resolución de dependencias de esta del paquete lo instalará también.
Creando un proyecto y activando el entorno de desarollo para C++/GTK
Arrancamos Eclipse, abrimos el menú contextual desde el explorador de proyectos, seleccionamos “New Project” > “C++ Project”.
Creando un nuevo proyecto en C++
Vamos a crear una carpeta de código fuente y a incluir un fichero de C++ con un ejemplo muy simple de ventana en GTK para Gnome 3. Al final usaremos este código, en las primeras imágenes hemos usado una versión más corta para probar el autocompletado más tarde:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
| #include <gtkmm.h>
#include <gtkmm/button.h>
int main(int argc, char *argv[])
{
Gtk::Main kit(argc, argv);
Gtk::Window window;
Gtk::Button button("Hello World");
window.add(button);
button.show();
Gtk::Main::run(window);
return EXIT_SUCCESS;
} |
Como se puede ver en la imagen, Eclipse no reconoce ni las cabeceras ni las instrucciones de gtkmm.
Eclipse marca la semántica de gtkmm no reconocida
El primer paso será hacer que Eclipse reconozca la semántica y el autocompletado de código para gtkmm. Para ello, tenemos que indicarle a Eclipse en qué directorio puede encontrar los archivos de cabecera y las definiciones de funciones y símbolos necesarios. En el explorador de proyectos de Eclipse, pulsamos el botón derecho sobre el nombre del proyecto y elegimos la opción “Properties” del menú contextual.
A continuación navegamos a través de las opciones de la barra lateral hasta alcanzar las opciones de construcción del proyecto(C/C++ Build ->Settings->GCC C++ Compiler->Includes). Usando el botón de añadir, añadimos el directorio donde se encuentran las cabeceras de gtkmm en nuestro sistema operativo. En Fedora 16, ese directorio se encuentra en la ruta /usr/include/gtkmm.
Incluyendo los archivos de cabecera de gtkmm para habilitar el autocompletado y el reconocimiento de sintaxis
Configurando el compilador
Mediante la combinación de teclas CTRL+B le indicaremos a Eclipse que compile y enlace los archivos binarios a partir del código fuente. En el estado actual, Eclipse no será capaz de compilar porque pese a poder resolver los símbolos específicos de gtkmm, no será capaz de resolver las referencias a otros símbolos dentro de gtkmm.h, así como enlazar los archivos binarios de objetos donde se implementa la funcionalidad de GTK. Para ayudarnos a configurar de manera rápida el compilador y la localización en el sistema de archivos de las dependencias viene en nuestra la herramienta pkg-config.
Resolviendo dependencias de una manera rápida y sencilla con pkg-config
Lo que viene a continuación es una pequeña explicación de como funciona pkg-config. Si ya sabes como funciona, o te da igual mientras funcione, pasa al
siguiente apartadopkg-config es, a grosso modo y entre otras cosas, una herramienta de configuración y resolución de dependencias. Permite a través de una cadena que representa una librería o recurso obtener una cadena de texto preformateada según el estandar de argumentos de entrada de gcc que contiene las definiciones necesarias para poder compilar el recurso especificado.
Un ejemplo es la mejor manera entender como funciona. Si ejecutamos el siguiente comando desde la consola:
[user@laptop]$ pkg-config --libs --cflags gtkmm-3.0
-DGSEAL_ENABLE -pthread -I/usr/include/gtkmm-3.0 -I/usr/lib64/gtkmm-3.0/include -I/usr/include/atkmm-1.6 -I/usr/include/giomm-2.4 -I/usr/lib64/giomm-2.4/include -I/usr/include/pangomm-1.4 -I/usr/lib64/pangomm-1.4/include -I/usr/include/gtk-3.0 -I/usr/include/cairomm-1.0 -I/usr/lib64/cairomm-1.0/include -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/gtk-3.0/unix-print -I/usr/include/gdkmm-3.0 -I/usr/lib64/gdkmm-3.0/include -I/usr/include/atk-1.0 -I/usr/include/glibmm-2.4 -I/usr/lib64/glibmm-2.4/include -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/sigc++-2.0 -I/usr/lib64/sigc++-2.0/include -I/usr/include/pango-1.0 -I/usr/include/cairo -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng12 -pthread -lgtkmm-3.0 -latkmm-1.6 -lgdkmm-3.0 -lgiomm-2.4 -lpangomm-1.4 -lgtk-3 -lglibmm-2.4 -lcairomm-1.0 -lgdk-3 -latk-1.0 -lgio-2.0 -lpangoft2-1.0 -lpangocairo-1.0 -lgdk_pixbuf-2.0 -lcairo-gobject -lpango-1.0 -lfreetype -lfontconfig -lgmodule-2.0 -lcairo -lsigc-2.0 -lgobject-2.0 -lgthread-2.0 -lrt -lglib-2.0
[user@laptop]$ _
La linea de retorno de la instrucción(la segunda), sería la lista de argumentos que habría que pasarle al compilador para que pueda resolver las dependencias de un archivo de código fuente que use cualquier recurso de gtkmm versión 3.0.
Como puede verse, mediante el argumento de compilador -I se incluyen los directorios donde se encuentran las cabeceras y archivos de objetos, dependientes del sistema operativo y la configuración local del usuario. Quizás os suene la importación -I/usr/include/gtkmm-3.0, que especifica el directorio que hemos usado antes para activar el autocompletado en Eclipse. También es interesante ver que especifica las opciones -lgkt-3 -lgtkmm-3.0, que mediante la opción -l de gcc especifica que se va a usar la librería gtkmmm para el enlazado.
En esta llamada a pkg-config hemos usado tres argumentos:
- --cflags: ordena a pkg-config que devuelva en la cadena todos los argumentos que el compilador necesitaría para poder compilar(ojo, no enlazar) un código fuente que contenga referencia a recursos y símbolos agrupados en el paquete de nombre especificado.
- --libs: ordena a pkg-config que devuelva en la cadena todos los argumentos que el enlazador necesitaría para poder enlazar código fuente y objetos que contengan referencias a recursos y símbolos agrupados en el paquete de nombre especificado.
- gtkmm-3.0: es el nombre del recurso, también llamado paquete, para el cual se quieren obtener las dependencias. Los paquetes con las definiciones de dependencias normalmente se instalan automáticamente cuando instalamos el paquete de desarrollo concreto mediante el gestor de paquetes de nuestro sistema operativo. Por ejemplo, cuando antes hicimos:
yum install gtkmm30-devel
en alguna parte del sistema de archivos se instaló un archivo llamado “gtkmm-3.0.pc” que contenía las definiciones de dependencias para gtkmm.
Aparte del paquete que hemos usado para gtkmm versión 3, existen otros paquetes como gtk+3.0 o zlib. Por poner un ejemplo, considerando la instalación de mi sistema operativo similar a la de cualquier programador, más de 120 paquetes de resolución de dependencias están instalados. Las definiciones de paquetes instaladas en el sistema operativo pueden mostrarse ejecutando el siguiente comando:
pkg-config --list-all
También existen paquetes de dependencias para versiones antiguas y para compilado multiplataforma. Si hubiésemos querido obtener las dependecias para gtkmm 2.4 en vez de la 3.0, nos hubiera bastado con cambiar el nombre del paquete a gtkmm+2.4.
Llegados a este punto, la potencia de pkg-config viene de la combinación de esta orden con la sintaxis específica de bash. Una sentencia que contenga otra sentencia en la misma línea encerrada entre comas francesas 「`」 se ejecutará sustituyendo el contenido de las comas por la cadena de salida de la sentencia entre comas. Un ejemplo:
[user@laptop]$ echo "Esto está fuera de las comas francesas`echo "'Y esto está dentro de las comas'"`"
"Esto está fuera de las comas francesas 'Y esto está dentro de las comas'"
[user@laptop]$ _
La utilidad de esta funcionalidad se demuestra al permitirnos combinar gcc y pkg-config de la siguiente manera:
[user@laptop]$ g++ main.cpp -o main.bin `pkg-config --libs --cflags gtkmm-3.0`
[user@laptop]$ _
Podemos saber cuál es realmente el comando ejecutado usando echo de la siguiente manera:
[user@laptop]$ echo "g++ main.cpp -o main.bin `pkg-config --libs --cflags gtkmm-3.0`"
"g++ main.cpp -o main.bin -DGSEAL_ENABLE -pthread -I/usr/include/gtkmm-3.0 -I/usr/lib64/gtkmm-3.0/include -I/usr/include/atkmm-1.6 -I/usr/include/giomm-2.4 -I/usr/lib64/giomm-2.4/include -I/usr/include/pangomm-1.4 -I/usr/lib64/pangomm-1.4/include -I/usr/include/gtk-3.0 -I/usr/include/cairomm-1.0 -I/usr/lib64/cairomm-1.0/include -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/gtk-3.0/unix-print -I/usr/include/gdkmm-3.0 -I/usr/lib64/gdkmm-3.0/include -I/usr/include/atk-1.0 -I/usr/include/glibmm-2.4 -I/usr/lib64/glibmm-2.4/include -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/sigc++-2.0 -I/usr/lib64/sigc++-2.0/include -I/usr/include/pango-1.0 -I/usr/include/cairo -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng12 -pthread -lgtkmm-3.0 -latkmm-1.6 -lgdkmm-3.0 -lgiomm-2.4 -lpangomm-1.4 -lgtk-3 -lglibmm-2.4 -lcairomm-1.0 -lgdk-3 -latk-1.0 -lgio-2.0 -lpangoft2-1.0 -lpangocairo-1.0 -lgdk_pixbuf-2.0 -lcairo-gobject -lpango-1.0 -lfreetype -lfontconfig -lgmodule-2.0 -lcairo -lsigc-2.0 -lgobject-2.0 -lgthread-2.0 -lrt -lglib-2.0"
[user@laptop]$ _
Se ve el resultado, ¿No? La sentencia anterior compila el archivo main.cpp y expande la orden pkg-config de tal forma que añade al final de la sentencia todas los argumentos necesarios para resolver cualquier dependencia necesaria para gtkmm. Esta instrucción con esta sintaxis tan elegante soluciona de una tacada la mayoría de los problemas de compilación dependiente del entorno y nos va a servir ahora para finiquitar la configuración de compilación de Eclipse de una manera rápida y sencilla.
Resolviendo dependencias en Eclipse usando pkg-config
Finalmente, vamos a lograr compilar el programa anterior añadiendo la sentencia pkg-config a la configuración de montaje de Eclipse. Abrimos el menú de configuración del proyecto pulsando el botón derecho sobre el nombre del proyecto y seleccionamos “Properties/Propiedades”.
Primero configuramos el compilador para añadirle dependencias. Seleccionamos “C/C++ Build ->Settings->GCC C++ Compiler->Miscellaneous” y en el campo de texto “Other flags” añadimos el siguiente token:
`pkg-config --cflags gtkmm-3.0`
Atención con las comas francesas 「`」, son importantes. Consulta el apartado “Resolviendo dependencias de una manera rápida y sencilla con pkg-config” para más información.
Configurando la resolución de dependencias en el compilador de eclipse con pkg-config
A continuación vamos a configurar el enlazador. Seleccionamos también desde el menú propiedades del proyecto ”C/C++ Build ->Settings->GCC C++ Linker->Miscellaneous” y en el campo de texto “Linker flags” añadimos el siguiente token:
`pkg-config --libs gtkmm-3.0`
Atención con las comas francesas 「`」, son importantes. Consulta el apartado “Resolviendo dependencias de una manera rápida y sencilla con pkg-config” para más información.
Configurando la resolución de dependencias en el enlazador de Eclipse con pkg-config
Técnicamente está listo para construir el proyecto. Lo que hemos hecho es indicar a Eclipse que añada las sentencias de resolución de dependencias al final de la instrucción que usa para llamar al gcc.
Compilando…¡Hola Mundo!
En Eclipse-CDT podemos configurar varias configuraciones de compilación personalizadas. Por defecto, Eclipse añade a todos los proyectos nuevos las configuraciones “Debug” y “Release”, aplica la primera por defecto. Toda la configuración que hemos hecho hasta ahora se ha aplicado a la configuración de “Debug”, así que si en este momento compilar mediante “Release” obtendremos el mismo resultado que al principio. Habría que reconfigurar de nuevo “Release” o cualquier nueva configuración de manera análoga a lo hecho anteriormente para hacerlo funcionar.
Si pulsamos CTRL+B construiremos el proyecto usando la configuración por defecto “Debug”. La salida por consola debería ser algo parecido a los siguiente:
**** Build of configuration Debug for project Hola_Mundo ****
make all
Building file: ../src/main.cpp
Invoking: GCC C++ Compiler
g++ -I/usr/include/gtkmm-3.0 -O0 -g3 -Wall -c -fmessage-length=0 `pkg-config --cflags gtkmm-3.0` -MMD -MP -MF"src/main.d" -MT"src/main.d" -o "src/main.o" "../src/main.cpp"
Finished building: ../src/main.cpp
Building target: Hola_Mundo
Invoking: GCC C++ Linker
g++ `pkg-config --libs gtkmm-3.0` -o "Hola_Mundo" ./src/main.o
Finished building target: Hola_Mundo
**** Build Finished ****
Eclipse genera una carpeta con el nombre de la configuración en la cual crea todos los archivos necesarios para construir el proyecto basándose en la configuración de construcción de éste. Por ejemplo, para la configuración “Debug” creará una carpeta de mismo nombre en la raíz del proyecto conteniendo el código objeto, una estructura de makefile, el binario,etc..
La carpeta "Debug" y todo su contenido fueron autogenerados después de construir el proyecto
Ninguno de los archivos autogenerados al construir el proyecto debe ser modificado manualmente. Eclipse reescribe todos los archivos cada vez que se le ordena construir el proyecto, así que todos los cambios se perderán. Si quieres editar alguna de las configuraciones, por ejemplo la del makefile, tendrás que hacerlo cambiando el campo correspondiente en las opciones del proyecto.
Si pulsamos CTRL+F11 ordenaremos a Eclipse arrancar la última versión construida del proyecto. ¡Hola Mundo!
¡Hola Mundo!
Cargando tweets...