Como ya debes saber, lo primero que necesitamos para programar es un editor de texto. Uno de los primeros resultados del proyecto GNU fue el editor emacs, y los editores estuvieron entre los primeros programas que se portaron a Linux.

Pero vamos a centrar nuestra atención en el editor vim, el cual es básicamente una interfaz basada en pantallas escrita con base en ex (otro editor muy antiguo).

En la mayoría de los distros de Linux encontrarás el editor vim. Aunque muchas personas piensan que vim es enigmático y difícil de utilizar, por lo general es porque nos acostumbramos al bloc de notas de Windows, emacs (en modo gráfico) y/o a los IDE's (a lo fácil); sin embargo, vim tiene muchas ventajas con respecto a otros editores:

• Está disponible en prácticamente en todos los sistemas UNIX y Linux.
• Necesita menos recursos de sistema que emacs, y por consecuencia se ejecuta aunque el sistema no esté funcionando completamente.
• No es tan personalizable como el emacs, por lo que sus implementaciones se comportan casi de la misma manera.

Puedes utilizar cualquier otro editor de texto, aunque te recomiendo que domines los fundamentos del vim. Para comenzar puedes leerte este pequeño (muy pequeño) artículo acerca del vim.

ctags y etags

Al codificar un programa grande en C++, talvez sea necesario dividir las clases y métodos en archivos fuente separados. Pero después, al depurar el programa, puede resultar tediosa la tarea de navegar entre archivos. Por ejemplo, talvez esté editando el archivo A y en él haya una invocación a un método que se encuentre en otro fichero, talvez el B. Los programas ctags y etags generan archivos índice o “tag”, que vi y emacs pueden utilizar para ayudarlo a navegar por sus archivos fuente.

ctags genera marcas para vim, pero se puede configurar para que lo haga para emacs. etags genera marcas para emacs, pero se puede configurar para que lo haga para vim.

Vamos a ver un ejemplo del ctag con vim. Para ello escribimos el siguiente código en un archivo llamado HolaPrincipal.cpp:

//HolaPrincipal.cpp
#include<iostream>
using namespace std;
void Saludar(int i);
int main(int argc, char * argv[])
{
for(int i=0; i<5; i++)
{
Saludar(i);
cout<<endl;
}
}

y lo siguiente en Saludar.cpp:

//Saludar.cpp
#include<iostream>
using namespace std;
void Saludar(int i)
{
cout<<"["<<i<<"] elhackerr00lz";
}

Ahora vamos al directorio donde tenemos los dos archivos y escribimos el comando:

ctags *.cpp

Hemos creado el nuevo archivo tags. Ahora vamos a probarlo, para ello abrimos el archivo HolaPrincipal.cpp (vim HolaPrincipal.cpp); y usando las flechitas de dirección colocamos el cursor sobre la palabra Saludar. Oprime Ctrl+], y verás que el editor abre automáticamente el archivo que contiene la función (Saludar.cpp) y coloca el cursor al inicio de la misma.

Como he dicho anteriormente solo centraremos la atención al vim, para el emacs puedes manejar tanto el ctags como el etags. Utiliza la información en línea para ver como se utiliza.

El compilador C de GNU se llama gcc y puede compilar C, C++ y Objective-C. El compilador de C se apega al estándar ANSI, por lo que es fácil de portar un programa C ANSI a Linux.

Cómo compilar con gcc

El compilador GNU se invoca con el comando gcc. De manera predeterminada este comando preprocesará, compilará y en enlazará un programa de C. Existen muchas opciones para el gcc, y entre ellas existen controles que permiten ejecutar solo alguna fase de la secuencia preproceso/compilación/enlace.

El siguiente ejemplo sencillo es un programa en C que simula el lanzamiento de un dado n veces, y luego imprime el número de veces que sale cada una de sus caras. Nota: El ejemplo lo saqué de un libro de C, espero no me demanden.

Crea el archivo juego.c:

#include<stdio.h>
#include<stdlib.h>
#include<string.h>

int tirarDado(void);

int main(int argc, char * argv[])
{
int i, iIter, dado[6];

if(argc<2)
{
printf("Uso: %s n\n",argv[0]);
return 1;
}
iIter = atoi(argv[1]);
memset(dado, 0, sizeof(dado));
for(i=0; i<iIter; i++)
{
dado[tirarDado() - 1]++;
}
printf("%d tiradas\n",iIter);
printf("\tCara\tTiradas\n");
for(i=0; i<6; i++)
{
printf("\t%d : \t%d\n",i+1, dado[i]);
}
}

Y el archivo tirador.c:

#include<stdlib.h>
int tirarDado(void)
{
return (rand()%6+1);
}

Podríamos utilizar un solo comando para compilar y crear el programa ejecutable:

gcc -o juego juego.c tirador.c

Puede ver que -o indica el nombre del archivo de salida (el ejecutable). gcc sabe que los archivos con la extensión *.c son archivos de C y los compila como tales. Sino especifica un nombre de archivo de salida, gcc creará predeterminadamente el archivo a.out.

Ahora veamos otra manera de compilar nuestro programa: haciéndolo por módulos (por separado):

gcc -c juego.c
gcc -c tirador.c
gcc -o juego juego.o tirador.o

En este caso indicamos al compilador, con la opción -c, que primero el archivo juego.c, luego el archivo tirador.c. Y por último le indicamos que cree el archivo binario ejecutable, utilizando los dos archivos objeto (resultados de la compilación): juego.o y tirador.o.

Cómo compilar con g++

El comando g++ nos permite compilar archivos de C++. Aunque gcc puede compilar programas de C++, no hace automáticamente todos los enlaces requeridos con las bibliotecas de clases. Necesita usar g++ para esto. Por ello es recomendable que utilices g++ si estás utilizando C++.

Ahora vamos a compilar la versión C++ de nuestro programa de los dados; el archivo juego.cpp:

#include<iostream>
#include<stdlib.h>
#include<string.h>
using namespace std;
int tirarDado(void);
int main(int argc, char * argv[])
{
int i, iIter, dado[6];
if(argc<2)
{
cout<<"Uso: "<<argv[0]<<"n\n";
return 1;
}
iIter = atoi(argv[1]);
memset(dado, 0, sizeof(dado));
for(i=0; i<iIter; i++)
{
dado[tirarDado() - 1]++;
}
cout<<iIter<<" tiradas\n";
cout<<"\tCara\tTiradas\n";
for(i=0; i<6; i++)
{
cout<<"\t"<<i+1<<" :\t"<<dado[i]<<endl;
}
}

El archivo tirador.cpp:

#include<stdlib.h>
int tirarDado(void)
{
return (rand()%6+1);
}

La compilación en g++ es muy similar a gcc en casi todos los aspectos. Para compilar con un solo comando utiliza:

g++ -o juego juego.cpp tirador.cpp

Y para compilar por módulos:

g++ -c juego.cpp
g++ -c tirador.cpp
g++ -o juego juego.o tirador.o

ELF
Cuando se compila un programa, se genera un archivo objeto, y cuando se enlaza el programa, se crea un archivo binario ejecutable. El enlazador debe entender el formato de los archivos objeto, y como el sistema operativo debe cargar y ejecutar el programa ejecutable, también debe entender este formato.
Ya vio que el archivo ejecutable por defecto se llama a.out. Hace un tiempo, el formato de los archivos objeto y los archivos ejecutables se conocía como a.out. Este formato es muy antiguo y contiene bastantes defectos. El formato actual, utilizado por los sistemas UNIX y Linux se conoce como ELF (Formato Ejecutable y de Enlace). ELF es mucho más versátil que a.out, y se presta muy bien para crear bibliotecas compartidas (librerías dinámicas).

Puede saber cual es el formato de un archivo utilizando el comando file, por ej.:

file juego tirador.o /usr/bin/apt-get
juego: ELF 32-bit LSB executable, Intel 80386...
tirador.o: ELF 32-bit LSB relocatable, Intel 80386...
/usr/bin/apt-get: ELF 32-bit LSB executable, Intel 80386...

A veces, varios programas necesitan hacer las mismas cosas, como E/S por ejemplo. Hace ya bastante tiempo se desarrolló el concepto de biblioteca (o librería) para adaptar esto. Las funciones se colocan en un archivo, y luego, cada vez que se crea un programa, este extrae de la biblioteca las funciones que necesita.

En su momento, esto fue un gran avance, pero tenía varias desventajas. Los ejecutables se hacen más grandes ya que cada uno de ellos incrusta código copiado de las bibliotecas. Si se encuentra un error en la biblioteca o se agrega una característica, el ejecutable no hace uso de ella a menos que se vuelva a crear.

La solución a esto son las bibliotecas compartidas (o librerías dinámicas). El mecanismo de las bibliotecas compartidas esta fuera del alcance de este artículo. Solo veremos como crearlas y utilizarlas.

Regresemos al programa del dado que hicimos en C. Este programa tiene dos archivos fuente. Supongamos que nuestra función tirarDado (del archivo tirador.c) nos es muy útil, no solo en nuestro programa, sino en muchos otros programas que utilicen dados. Podemos pensar entonces en colocar dicha función en una biblioteca para que otros programas puedan usarla.

Primero necesitamos crear la biblioteca compartida. Para ello compilamos el archivo que contiene la función así:

gcc -fPIC -c tirador.c

Ahora lo convertimos en una biblioteca compartida llamada libtirar.so.1.0:

gcc -shared -Wl,-soname,libtirar.so.1 -o libtirar.so.1.0 tirador.o

Por último crearemos un enlace para libtirar.so, para que el programa en ejecución no necesite mantener un registro de la información de versión en el nombre de la biblioteca compartida:

ln -s libtirar.so.1.0 libtirar.so.1
ln -s libtirar.so.1 libtirar.so

Ahora que tenemos la biblioteca, debemos crear el programa principal para que enlace con esa biblioteca en tiempo de ejecución, en lugar de incluir el código dentro del ejecutable:

gcc -o juego juego.c -L. -ltirar

La opción -L. le indica al compilador que busque bibliotecas en el directorio actual, y la opción -ltirar le indica que busque una biblioteca llamada libtirar.so.

Al ejecutar el programa, el sistema operativo cargará dinámicamente la biblioteca correcta, pero tiene que saber donde buscarla. Si la biblioteca no se encuentra en un lugar estándar (/usr/lib por ejemplo), puede asignar una variable de entorno para que le indique en dónde localizar bibliotecas adicionales:

export LD_LIBRARY_PATH=/home/usuario/mislibrerias

Por último, para ver qué librerías usa un programa, utilice el comando ldd:

ldd juego
libtirar.so.1 =>/mnt/hda1/home/casidiablo/juegolibrerias/libtirar.so.1 (0x40018000)
libc.so.6 => /lib/libc.so.6 (0x40029000)
/lib/ld-linux.so.2 =>/lib/ld-linux.so.2 (0x40000000)

Otro ejemplo de bibliotecas... crear una biblioteca estática

A diferencia de las bibliotecas compartidas, al momento de compilar bibliotecas estáticas, se incluyen en el programa las rutinas que utiliza de la biblioteca; en otras palabras las rutinas están insertas en el programa sin la posibilidad de ser utilizados por otro programa. Nuestra demostración se basará en la construcción de una biblioteca estática; dentro de nuestra biblioteca incluiremos un procedimiento que imprimirá un mensaje en pantalla el que será pasado por parámetro y una función que nos entrega en cálculo del factorial de un numero dado (pasado por parámetro); para que luego estas rutinas sean llamadas desde un programa de ejemplo.

El proceso para crear bibliotecas estáticas es escribir el código fuente, compilar a código objeto el fuente y crear la biblioteca con los archivos objetos. A continuación procederemos a escribir nuestras rutinas que serán incluidas en la biblioteca, los archivo de las rutinas serán factorial.c e imprimir.c

//imprimir.c
#include<stdio.h>
void imprimir_en_pantalla(const char* mensaje)
{
printf("%s",mensaje);
}

//factorial.c
#include<stdio.h>
long factorial(long numero)
{
if(numero>0)
return numero * factorial(numero-1);
else return 1;
}

Ahora compilaremos estos archivos fuente y los convertiremos en código objeto utilizando gcc:

gcc -c imprimir.c factorial.c

Esto creará los archivos objeto (imprimir.o y factorial.o). El siguiente paso será crear nuestra biblioteca estática con estos archivos de código objeto; a la biblioteca la llamaremos libejemploestatica.a:

ar rsc libejemploestatica.a imprimir.o factorial.o

El comando ar creará nuestra biblioteca (opcion c), introducirá los archivos objeto al archivo creado (opción r) y por último creará un índice de los módulos (opción s), esto último permite que el linker (ld) al momento de compilar (ld es llamado por gcc) no tenga que leerse toda la biblioteca completa ya que se agregan los índices y descripción de los módulos. El proceso de crear el índice de los módulos también se pude realizar con ranlib.

//miprograma.c
#include<stdio.h>
#include "libejemploestatica.h"
int main()
{
printf("Programa de ejemplo de utilizacion de biblioteca\n");
imprimir_en_pantalla("Vamos a calcular un factorial\n");
printf("El valor del factorial de 4 es: %i\n",factorial(4));
}

Ahora nos falta crear nuestro archivo de cabecera (header), que son los que tienen terminación .h, en este archivo se incluirán las llamadas a las rutinas de la biblioteca y es una manera elegante porque también puedes incluir estas llamadas en el programa que las vas utilizar. El archivo de cabecera libejemploestatica.h tendrá el siguiente contenido:

extern void imprimir_en_pantalla(const char*);
extern long fatorial(long);

No es necesario que el archivo de cabecera y biblioteca sean iguales antes de la extensión. Ahora crearemos el archivo ejecutable en base a nuestro programa principal (miprograma.c), el cual utilizará la biblioteca que hemos creado. Para ello debemos compilarlo utilizando la biblioteca:

gcc -o programa_ejecutable miprograma.c -L. -lejemploestatica

Con la opción -L indicamos donde se encuentra nuestro archivo de cabecera, como en este se encuentra en el mismo directorio utilizamos el punto (-L.). Con la opción -l indicamos el nombre de la librería. Fíjate que no es necesario colocar el nombre completo (libejemploestatica) ya que gcc asume que los nombre de bibliotecas empiezan con el prefijo "lib". Ahora ya tendremos el archivo ejecutable listo para correr nuestro programa:

$ ./programa_ejecutable
Programa de ejemplo de utilizacion de biblioteca
Vamos a calcular un factorial
El valor del factorial de 4 es: 24

Cuando creamos pequeños programas como los que hemos hecho hasta ahora, no resulta muy difícil el proceso de compilación y enlace. Pero cuando se crean proyectos grandes, con varios archivos fuente (15, 30 o más) y librerías resultaría muy difícil o hasta imposible.

Linux viene con la utilería make de GNU. make lee de un archivo conocido como make toda la información que necesita para crear su programa. Ésta utilería es tan importante y popular que se ha especificado como estándar de POSIX.

make

make de GNU busca automáticamente un archivo make llamado GNUmakefile. Sino lo encuentra, busca makefile, y si tampoco lo encuentra busca Makefile, y si tampoco lo encuentra dice “que mierdas, no juegues conmigo que no me gusta perder tiempo” XD. Estos son los nombres predeterminados, pero puedes crear un archivo con el nombre que quieras y especificar al make que lo utilice. Los archivos make contienen información acerca de la compilación y enlace de su programa, con una sintaxis muy específica que make puede entender.

make tiene una gran variedad de reglas integradas. Por ejemplo, sabe que los archivos que terminan con .c son archivos fuente de C, y sabe cómo compilarlos para convertirlos en archivos objeto (.o). Puedes redefinir cualquiera de estas reglas si gustas. En el caso más simple, todo lo que necesitas especificar en tu archivo make es el nombre que va a tener su archivo ejecutable, así como los archivos .o que se necesitan para crearlo.

He aquí un archivo sencillo para make, que creará el programa de los dados:

juego:juego.o tirador.o
$(CC) -o $@ juego.o tirador.o

Ahora podrás crear el programa con tan solo un comando: make.

Hay ocasiones en las que hay que indicar como compilar cierto tipo de archivo, por ejemplo cuando se utilizan otro tipo de extensiones (.cpp, .cxx, .c++). El error que se generaría sería similar a este:

make: *** No hay ninguna regla para construir el objetivo 'juego.o', necesario para 'juego'. Alto.

Vamos a ver un ejemplo de archivo makefile en donde se especifica explícitamente como construir dichos archivos objeto:

juegodados: juego.o tirador.o
$(CC) -o $@ juego.o tirador.o
juego.o: juego.c
$(CC) -c juego.c
tirador.o: tirador.c
$(CC) -c tirador.c

Ahora veamos un archivo makefile aún más completo:

#Makefile para crear programa para tirar dados
CFLAGS = -O
OBJS = juego.o tirador.o
all=dado
juego: $(OBJS)
$(CC) $(CFLAGS) -o $@ $(OBJS)
juego.o: juego.c
$(CC) -c juego.c
tirador.o: tirador.c
$(CC) -c tirador.c
clean:
-$(RM) dado *.o

Este archivo make define una regla llamada clean, que se utiliza para eliminar todos los archivos previamente compilados (incluso el ejecutable) y empezar con un directorio limpio. Fíjate también que se pueden declarar una especie de variables (como CFLAGS, OBJS, etc.), que se pueden utilizar al momento de indicar algún comando. Además fíjate que se pueden utilizar comentarios con el símbolo #.

Y un último ejemplo más complejo no nos vendría mal. Vamos a ver como sería nuestro archivo makefile, si deseáramos utilizar bibliotecas compartidas (librerías dinámicas):

#Makefile para crear programa para tirar dados
#usando bibliotecas compartidas
CFLAGS = -O
OBJS = juego.o
LIBS=libtirar.so
all=dado
juego: $(OBJS) $(LIBS)
$(CC) $(CFLAGS) -o $@ $(OBJS) -L. -ltirar
juego.o: juego.c
$(CC) -c juego.c
tirador.o: tirador.c
$(CC) -fPIC -c $<
libtirar.so: tirador.o
-$(RM) libtirar*
$(CC) -shared -Wl,-soname,libtirar.so.1 \
-o libtirar.so.1.0 $<
ln -slibtirar.so.1.0 libtirar.so.1
ln -slibtirar.so.1 libtirar.so
clean:
-$(RM) dado *.o libtirar*

Importante!!!
Sino quieres tener problemas en el futuro lee esto: la sintaxis de make nos obliga a respetar los separadores. ¿qué son separadores? talvez te hayas fijado en la forma en que están tabulados los archivos. Esto no es maña mía ni mucho menos, esto es una regla para los archivos make; sino se tabularan lo más seguro es que en la ejecución del make apareciera este error:

makefile:2: *** falta un separador. Alto.

Así que por lo que más quieras: utiliza los separadores si quieres que funcione.

Opciones de línea de comandos de make

make tiene varias opciones útiles de línea de comandos. Por ej., si quieres especificar un archivo make alternativo, en lugar de los predeterminados, invoca a make de la siguiente forma:

make -f nombrearchivo

make es un programa muy sofisticado. Una de las cosas que hace es comprender las dependencias. Por ejemplo, sabe que los archivos .o se crean a partir de archivos .c. Tu programa puede consistir en varios archivos fuente .c. Si cambias uno, no es necesario volver a compilarlos todos cada vez que vayas a crearlo. Sólo necesitas volver a compilar el archivo fuente que haya cambiado. make comprende esto y compila solo aquellos archivos que no estén actualizados. Algunas veces será necesario que veas primero qué es lo que make necesita para crear el programa. Puedes hacer esto con el siguiente comando:
make -n
Esto le indica a make que analice el makefile y que reporte qué comandos emitirá para crear el programa. make no ejecutará ningún comando.

Todo buen entorno de desarrollo debe proporcionar la capacidad de depurar nuestros programas, por ello Linux posee una herramienta llamada gdb. gdb es una excelente herramienta de depuración con interfaz de línea de comandos (modo texto). Aunque existen herramientas como gdbtui que es una versión del mismo depurador con una interfaz más amigable (pero en modo texto también). Y si sos de los que les da pereza la consola, tranquilo, también existe una herramienta llamada xxgdb que es una versión del gdb con interfaz gráfica que se ejecuta en X Windows.

gdb

gdb le permite analizar el funcionamiento de un programa paso a paso, establecer puntos de interrupción (breakpoints), examinar y modificar variables por su nombre. Se puede utilizar tanto en programas de C como de C++. Si has manejado alguna vez depuradores y debuggers como el OllyDbg, el manejo de este se te hará realmente fácil.

Para preparar un programa para su depuración, es necesario compilarlo con la opción -g. Esto hace que en alguna parte del ejecutable, se guarde información del código fuente tal como es. De otra forma no prodrás usar el depurador de forma óptima. Si estás utilizando el make para crear los programas, puedes indicar esta opción en la variable CFLAGS (¿la recuerdas?), desde la línea de comandos así:

make CFLAGS=-g

Cuando hayas creado el programa, puedes comenzar la sesión de depuración con el comando: gdb dado. (Suponiendo que el ejecutable se llama dado):

GNU gdb 6.1-debian
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-linux"...
Using host libthread_db library "/lib/libthread_db.so.1".
(gdb)

Estamos frente al prompt del gdb, que se representa con los caracteres (gdb), indicándonos que podemos escribir los comandos a ejecutar. gdb tiene muchos comando disponibles, para verlos digita el siguiente comando:

(gdb) help

Como puedes observar, el comando help despliega la lista de clases de comandos existentes en el gdb, para ver las instrucciones de determinada clase de comandos, digita help seguido del nombre del comando, por ejemplo así:

(gdb) help breakpoints

Por último para salir del gdb presiona la tecla q. A continuación veremos una tabla con comandos más útiles para el gdb:

Sesión de ejemplo de depuración con gdb

Ahora vamos a ver un ejemplo de como trabaja esta herramienta. Habiendo creado ya el programa (el de los dados) con la opción -g así:

g++ -g -o dados *.c

Pasamos a correr el depurador:

gdb dados

Con lo que aparece lo siguiente:

GNU gdb 6.1-debian
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-linux"...Using host libthread_db library "/lib/libthread_db.so.1".

(gdb)

Vamos entonces a ver el código fuente de nuestro programa principal (el que contiene la función main), esto lo hacemos con el comando list y le indicamos de que línea a que línea queremos ver, en este caso de la 1 a la 25:

(gdb) list 1,25
1 #include<stdio.h>
2 #include<stdlib.h>
3 #include<string.h>
4
5 int tirarDado(void);
6
7 int main(int argc, char * argv[])
8 {
9 int i, iIter, dado[6];
10
11 if(argc<2)
12 {
13 printf("Uso: %s n\n",argv[0]);
14 return 1;
15 }
16 iIter = atoi(argv[1]);
17 memset(dado, 0, sizeof(dado));
18 for(i=0; i<iIter; i++)
19 {
20 dado[tirarDado() - 1]++;
21 }
22 printf("%d tiradas\n",iIter);
23 printf("\tCara\tTiradas\n");
24 for(i=0; i<6; i++)
25 {

Ahora establecemos un punto de interrupción (breakpoint), en la línea 16 (iIter = atoi(argv[1]);), que hará que le programa se detenga en este punto al correrlo:

(gdb) break 16
Breakpoint 1 at 0x804850b: file juego.c, line 16.

Corremos el programa con el comando run seguido de los argumentos:

(gdb) run 5
Starting program: /mnt/hda2/archivos/programas C/juego/dados 5
Breakpoint 1, main (argc=2, argv=0xbffffd24) at juego.c:16
16 iIter = atoi(argv[1]);
Current language: auto; currently c++

Y vemos como se ejecuta, y posteriormente para en la línea 16. Nos muestra el nombre de la función en donde nos encontramos (en este caso main), y nos muestra el trozo de código fuente. Ahora veamos el valor de la variable iIter, utilizando el comando print iIter. Es de resaltar que utilizamos el nombre real de la variable para referirnos a esta, y que al estar sobre la línea en el cual se asigna el valor a la variable, el valor que nos imprime es el de la variable sin inicializar:

(gdb) print iIter
$1 = -1073742556

Veamos entonces que pasa si saltamos a la siguiente instrucción, y volvemos a imprimir el valor de iIter:

(gdb) next
17 memset(dado, 0, sizeof(dado));
(gdb) print iIter
$2 = 5

En este caso si se imprime el valor actual de la variable iIter (5). Avancemos hasta la línea 20, y observemos que podemos utilizar print para imprimir el valor de retorno de una función:

(gdb) next
18 for(i=0; i<iIter; i++)
(gdb) next
20 dado[tirarDado() - 1]++;
(gdb) print tirarDado()
$3 = 2

Ahora observemos que al estar aún dentro del for, al terminar la línea 20 el gdb nos devuelve automáticamente hasta la línea 18 (que es donde se evalua la condición del for):

(gdb) next
18 for(i=0; i<iIter; i++)
(gdb) next
20 dado[tirarDado() - 1]++;

Ahora continuemos con la ejecución normal del programa y salgamos del gdb, para ello digitamos el comando cont y después q:

(gdb) cont
Continuing.
5 tiradas
Cara Tiradas
1 : 0
2 : 2
3 : 0
4 : 1
5 : 1
6 : 1
Program exited normally.
(gdb) q

Eso es todo!!! Fácil ¿no? para un manejo avanzado del gdb leer la documentación del programa localmente (comando man) o en Internet.

Los programas nunca son tan fáciles como se piensa que son al principio. Cualquier buen programa va más allá de su propósito original. Con el tiempo hay cambios, se agregan cosas, se solucionan errores y se hacen mejoras.

Los comentarios son una buena manera de mantener información acerca de los cambios, pero para cualquier trabajo serio se necesita alguna forma de control de versiones. Supongamos que cambias el programa juego.c, agregándole varias características. Un año después, tu cliente más importante te llama y te dice que no quiere todas esas características: que quiere la versión original del año pasado, en la que se había arreglado un error.

En Linux existe RCS (Sistema de Control de Revisiones). RCS es una colección de comandos que le permiten rastrear cambios realizados en archivos, recuperar cualquier versión anterior y comparar las versiones actuales con las más antiguas.

RCS

Los principales comandos de la suite RCS se muestran a continuación:

ci: Insertar en el depósito una nueva versión de un archivo.
co: Obtener la última versión de un archivo.
ident: Buscar identificadores de RCS en archivos.
merge: Crear una versión de un archivo que incorpore cambios de otras dos versiones de ese archivo.
rcsdiff: Comparar dos versiones de un archivo.
rlog: Ver el historial de un archivo.

RCS mantiene en un depósito el historial de las revisiones de los archivos. Por lo general, ese depósito es un directorio llamado RCS, que se encuentra en su directorio actual.

En el siguiente ejemplo, iniciamos el historial de RCS de un archivo en nuestro proyecto de tirar dados:

$ ci makefile
RCS/makefile,v <-- makefile
Enter description, terminated with single '.' or end file:
NOTE: This is NOT the log message!
>> Makefile del programa de tirar dados
>> .
initial version 1.1
done
$

Ahora hemos registrado el Makefile en el depósito de RCS, y RCS ha creado un archivo en el directorio RCS llamado Makefile,v. A medida que modifiquemos el Makefile y verifiquemos las versiones más recientes, RCS levará el registro de esos cambios en su copia Makefile,v.

Nota: Después de registrar un archivo en RCS, verás que tu archivo original ha desaparecido. No te asustes (gallina), no lo has perdido. RCS ha rastreado sus cambios en su copia y ha eliminado su original. Aún puede revisar su archivo con el comando co.

Registra todos los archivos necesarios para crear el programa de los dados, con los comandos ci juego.c y ci tirador.c.

$ ci *.c
RCS/juego.c,v <-- juego.c
Enter description, terminated with single '.' or end file:
NOTE: This is NOT the log message!
>> Archivo principal del programa tirar dados
>> .
initial version 1.1
done
RCS/tirador.c,v <-- tirador.c
Enter description, terminated with single '.' or end file:
NOTE: This is NOT the log message!
>> Archivo que contiene implementacion de la funcion tirardado()
>> .
initial version 1.1
done
$ ls
RCS
$

Piensa en RCS como si fuera una biblioteca que guarda tus archivos. Puedes sacar copias de solo lectura con el comando co nombrearchivo. Cuando quieras modificar un archivo, puedes sacar un copia el la que se pueda escribir (bloqueada) con co -l. Puedes sacar cualquier cantidad de copias de sólo lectura (desbloquedas) a la vez. Sólo puedes sacar una copia bloqueada a la vez. Por ejemplo:

$ co ./juego.c
./RCS/juego.c,v --> ./juego.c
revisison 1.1
done
$ ls -l
total 8
-r--r--r-- 1 root root 466 2007-02-28 14:41 juego.c
drwxr-xr-x 2 root root 4096 2007-02-28 14:37 RCS

En este caso sacamos el archivo juego.c como solo lectura. Si utilizamos el comando ls -l veremos en la parte de permisos -r--r--r-- lo que quiere decir que no podemos editar dicho archivo.

Hay varias palabras reservadas de identificación que puedes colocar en tu archivo y que son reconocidas por RCS. Estas palabras reservadas empiezan y terminan con $. Podriamos, por ejemplo, modificar el programa juego.c así:

#include<stdio.h>
#include<stdlib.h>
#include<string.h>

int tirarDado(void);

int main(int argc, char * argv[])
{
int i, iIter, dado[6];

if(argc<2)
{
printf("Uso: %s n\n",argv[0]);
return 1;
}
iIter = atoi(argv[1]);
memset(dado, 0, sizeof(dado));
for(i=0; i<iIter; i++)
{
dado[tirarDado() - 1]++;
}
printf("%d tiradas\n",iIter);
printf("\tCara\tTiradas\n");
for(i=0; i<6; i++)
{
printf("\t%d : \t%d\n",i+1, dado[i]);
}
printf("$Header$\n");
}

Para ello tendría que sacar el archivo bloqueado (con permisos de escritura), así:

$ co -l ./juego.c
./RCS/juego.c,v --> ./juego.c
revisison 1.1 (locked)
done
$ ls -l
total 8
-rw-r--r-- 1 root root 466 2007-02-28 14:43 juego.c
drwxr-xr-x 2 root root 4096 2007-02-28 14:43 RCS

Ahora sí podemos editar el archivo, ya que tiene permisos de lectura/escritura. Observemos que cuando saco el archivo desbloqueado (sólo lectura), RCS reemplaza la palabra reservada $Header$ con información acerca del nombre y la versión del archivo. Cuando lo saco bloqueado, RCS no reemplaza el encabezado.

Por último meto de nuevo el programa juego.c (ya modificado), creo el programa y lo ejecuto:

ci ./juego.c
./RCS/juego.c,v <-- ./juego.c
new revision: 1.2; previous revision: 1.1
enter log message, terminated with single '.' or end of file:
>> Le he agregado el Header
>> .
done
$ ls
RCS
$ make
co RCS/makefile,v makefile
RCS/makefile,v --> makefile
revision 1.1
done
co RCS/juego.c,v juego.c
RCS/juego.c,v --> juego.c
revision 1.2
done
cc -c juego.c
co RCS/tirador.c,v tirador.c
RCS/tirador.c,v --> tirador.c
revision 1.1
done
cc -c tirador.c
cc -O -o juego juego.o tirador.o
$ ls -l
total 40
-rwxr-xr-x 1 root root 12689 2007-02-28 14:52 juego
-r--r--r-- 1 root root 562 2007-02-28 14:52 juego.c
-rw-r--r-- 1 root root 1368 2007-02-28 14:52 juego.o
-r--r--r-- 1 root root 247 2007-02-28 14:52 makefile
drwxr-xr-x 2 root root 4096 2007-02-28 14:46 RCS
-r--r--r-- 1 root root 65 2007-02-28 14:52 tirador.c
-rw-r--r-- 1 root root 804 2007-02-28 14:52 tirador.o
$ ./juego 130
130 tiradas
Cara Tiradas
1 : 18
2 : 22
3 : 28
4 : 27
5 : 17
6 : 18
$Header: /mnt/doc/RCS/juego.c,v 1.2 2007/02/28 13:46:14 root Exp $
$

También podemos buscar identificadores dentro de un archivo, por ejemplo:

$ co ./juego.c
./RCS/juego.c,v --> ./juego.c
revisison 1.2
done
$ ident juego.c
juego.c:
$Header: /mnt/doc/RCS/juego.c,v 1.2 2007/02/28 13:46:14 root Exp $

Es posible ver que cambios se han realizado de una versión a otra, por ejemplo:

$ rlog ./juego.c
RCS file: ./RCS/juego.c,v
Working file: ./juego.c
head: 1.3
branch:
locks: strict
access list:
symbolic names:
keyword substitution: kv
total revisions: 3; selected revisions: 3
description:
Archivo principal del programa tirar dados
----------------------------
revision 1.3
date: 2007/02/28 14:32:09; author: root; state: Exp; lines: +2 -2
Le puse "numero de tiradas" en vez de "tiradas"
----------------------------
revision 1.2
date: 2007/02/28 13:46:14; author: root; state: Exp; lines: +3 -3
Le he agregado el Header
----------------------------
revision 1.1
date: 2007/02/28 13:36:34; author: root; state: Exp;
Initial revision

CVS

Para los que no sepan que es CVS, una pequeña introducción...

El Concurrent Versions System (CVS), también conocido como Concurrent Version System o Concurrent Versioning System, es una aplicación informática que implementa un sistema de control de versiones: mantiene el registro de todo el trabajo y los cambios en los ficheros (código fuente principalmente) que forman un proyecto (de programa) y permite que distintos desarrolladores (potencialmente situados a gran distancia) colaboren. CVS se ha hecho popular en el mundo del software libre. Sus desarrolladores difunden el sistema bajo la licencia GPL. Fragmento tomado de la Wikipedia.

Pero... ¿porqué RCS y no CVS? o ¿porqué CVS y no RCS? RCS es un sistema similar al CVS (Concurrent Versions System), de hecho CVS trabaja sobre RCS, con un repositorio (lugar donde se hace seguimiento de los cambios entre versiones), pero sin la parte de concurrencia. Es decir: RCS resulta conveniente cuando no hay varios desarrolladores trabajando sobre el mismo código fuente, que además pueden aplicar cambios de forma concurrente en el repositorio. Así que para pequeños proyectos con uno o más desarrolladores, pero con solo una persona encargada de aplicar los cambios, RCS es una opción a considerar.

Antes de empezar debemos tener claros ciertos conceptos:
repositorio: jerarquía de directorios alojada en el servidor que contiene diferentes módulos a disposición de los usuarios.
módulo: árbol de directorios que forma parte del repositorio; cuenta con un nombre identificador gracias al cual podremos bajárnoslo de forma selectiva.

La instalación la puedes hacer a través de apt-get, urmpi, emerge, o con el tarball. Lo más sencillo sería, si tienes Debian o un derivado, hacer:

apt-get install cvs cvs-doc cvsbook

Invocar a cvs

cvs es un programa que se invoca desde intérpretes de órdenes. según cómo sea su configuración (y estoy pensando en las diferentes formas de autenticación) lo podrás usar en procesos por lotes sin ningún problema.
Un aspecto que debes tener en cuenta (sobre todo si este es el primer documento que lees sobre cvs) es que cvs tiene parámetros para cada una de sus órdenes. para conocerlas tienes dos métodos: invocar cvs como «cvs help» o mirar la ayuda.

Configuración

Puedes usar varios ficheros de configuración que cvs reconocerá y usará. Los más importantes:

~/.cvsignore
que contiene los sufijos de los ficheros que no nos interesa que cvs controle: *.tex *.aux *.dvi *.ps *.log
~/.cvsrc
que contiene parámetros que cvs usará cada vez que se invoque:
cvs -z 3
update -Pd
diff -uw

La autenticación

Al trabajar en remoto con cvs pueden elegirse varias alternativas de autenticación (es decir, de demostrar al servidor que somos quienes decimos que somos). Las que más he visto usar son vía pserver y vía ssh. Deberás elegir alguna de estas técnicas en función de tus necesidades, las ganas que tengas de complicarte la vida y, sobre todo, del grado de neurosis obsesiva por la seguridad que padezcas.

ssh

Como uno va por la vida predicando el software libre no puedo más que recomendar el uso de OpenSSH que puede encontrarse en http://www.openssh.org. Si no me equivoco, esta herramienta es compatible con la norma ssh 1.x.

Para que cvs use este modo de autenticarse se pueden usar estas variables de entorno:

export CVSROOT=":ext:USUARIO@www.vivalavirgen.com:/home/cvs"
export CVS_RSH=/usr/bin/ssh

donde USUARIO es nuestro nombre de usuario; www.vivalavirgen.com es el servidor que aloja al repositorio; /home/cvs es el directorio del servidor en el que está el repositorio; /usr/bin/ssh es la ruta completa al amigo ssh.

Ten en cuenta que, usando esta técnica, tendrás que autenticarse (es decir, suministrar su contraseña) cada vez que ejecute cvs.

pserver

Esta técnica es más de «andar por casa». Se monta rápidamente y no necesita de programas añadidos.

export CVSROOT=":pserver:USUARIO@www.vivalavirgen.com:/home/cvs"

donde USUARIO es nuestro nombre de usuario; www.vivalavirgen.com es el servidor que aloja al repositorio; /home/cvs es el directorio del servidor en el que está el repositorio.

Si usa esta técnica, antes de poder trabajar con cvs debe autenticarse con el servidor. Eso se hace con la orden login:

$ cvs login

CVS le pedirá la contraseña del usuario que haya configurado. Si la contraseña es correcta cvs guardará la información que necesita en el fichero ~/.cvspass y no tendrá que volver a autenticarse. Si por algún motivo exotérico quisieras «cerrar la sesión cvs» bastará con hacer:

$ cvs logout

Modo de uso

A continuación se propone una sencilla metodología de trabajo con cvs para evitar trabajos redundantes. Piénsese por ejemplo en la eliminación de erratas o errores en documentos o en código fuente.
Antes de cada sesión de trabajo es conveniente hacer «cvs update» para asegurarnos de que disponemos de las últimas modificaciones.
Justo al acabar cada sesión de trabajo es conveniente hacer «cvs ci» para que todas nuestras modificaciones se propaguen en el servidor.

Bajar por primera vez el módulo

Para crear una copia de trabajo local del módulo cvs deseado debemos usar la orden co (o su equivalente checkout):

$ cd [padre-de-directorio-donde-se-alojará-el-módulo]
$ cvs co [nombre-del-módulo]

Esto creará una jerarquía de directorios donde se almacenará el módulo. Este paso sólo hay que hacerlo una vez por cada módulo. A partir de este momento no es necesario configurar las variables de entorno porque cvs sabe a qué repositorio pertenece el módulo con sólo examinar los subdirectorios CVS. No debes modificar nunca esos subdirectorios o volverás loco al pobre cvs.

Actualizar cambios

Cuando queramos actualizar la copia local del módulo con los cambios que hayan podido hacer otros usuarios y que ya han sido enviados al repositorio deberemos hacer:

$ cd [directorio-del-módulo]
$ cvs update

Observaréis que cvs informa acerca de qué está haciendo con cada fichero y para eso utiliza un código de una letra. Este es el significado:

U
Se ha bajado un fichero completamente nuevo.
P
Se ha bajado una modificación del fichero y ahora éste está actualizado.
A
El fichero lo ha añadido usted pero no lo ha subido todavía al repositorio.
R
El fichero ha sido borrado (pero podría recuperarse del histórico que se almacena en el repositorio).
C
Hay un conflicto: otra persona ha modificado antes las mismas partes del fichero y no le queda más remedio que revisarlo manualmente antes de poder subir los cambios de ese fichero.
M
Usted ha modificado el fichero pero aún no lo ha subido al repositorio.
?
CVS se ha encontrado un fichero que no tiene registrado y simplemente avisa y lo deja en paz.

Publicar nuestras modificaciones

Se usa la orden ci (o su equivalente commit):

$ cd [directorio-del-módulo]
$ cvs ci

Tras lo cual el sistema mostrará la pantalla de un editor de textos (el que tengamos configurado como nuestro favorito en las variables de entorno) para que describamos el cambio.

Resolución de conflictos

Tal cual la ONU habrá ocasiones en las que tengamos que resolver los conflictos que surjan entre diferentes versiones para que cvs continúe trabajando. Estos conflictos son normales y ocurren cuando dos o más personas modifican a la vez exactamente la mismas partes de un fichero. El procedimiento es simple:

• cvs se quejará de un fichero;
• editamos ese fichero;
• encontraremos unas marcas del tipo
  [...]
  >>>>>>>>>>>>>>
  taca
  ===========
  tacataca
  <<<<<<<<<<<<<<
  [...]
• El texto entre marcas es el que produce el conflicto. Hay que elegir qué modificación nos gusta y borramos todo lo demás.
• Si no quedan conflictos volvemos a hacer el «ci» y a ser felices.

Añadir ficheros al módulo

No olvides que cvs controlará sólo los ficheros que se le hayan indiciado expresamente. Cualquier otro fichero en el directorio cvs será ignorado.
Si quieres incluir un nuevo fichero o directorio al módulo cvs hay que seguir los siguientes pasos:

$ cd [directorio-del-módulo]
$ cvs add [fichero]

Pero si el fichero es binario hay que tener la precaución de hacer:

$ cd [directorio-del-módulo]
$ cvs add -kb [fichero]

¿Por qué?, se preguntará el lector más intrépido. Resulta que CVS usa varias variables (en realidad son de RCS, que funciona por debajo de CVS). Si el fichero es binario es posible que se de una combinación de bytes que coincidan con alguna de estas variables. Si así fuera, RCS/CVS modificaría el contenido y lo corrompería. También se debe a que el sistema de cálculo de diferencias que usan estos sistemas no está diseñado para trabajar con información binaria. Si se obra equivocadamente es probable que corrompamos los datos.
También quiero señalar que si bien se pueden gestionar ficheros binarios, no se hará control de versiones de los mismos. Sólo se guardará la última versión.
Tras el «add» hay que hacer un «cvs ci» para actualizar el servidor con los nuevos ficheros.

Eliminar ficheros del módulo cvs

Para eliminar un fichero del módulo cvs hay que hacer lo siguiente una vez borrado el fichero:

$ cd [directorio-del-módulo]
$ cvs remove [fichero]

En cambio, si queremos borrar físicamente los ficheros a la vez que los eliminamos del módulo deberemos usar:

$ cd [directorio-del-módulo]
$ cvs remove -f [fichero]

Cómo configurar un servidor y cómo subir nuevos módulos al repositorio. Si este documento es tu referencia favorita sobre cvs no merece la pena que te explique cómo se hacen estas cosas porque de todas formas no te ibas a enterar. Espabila un poco porque es bien fácil una vez que uno se ha mirado los manuales.

Si alguien con mejor corazón que yo tiene tiempo, que amplíe esta sección para beneficio de todos.

Herramientas con Interfaces gráficas para CVS

Espero que si llegas a este punto es por curiosidad o por la inercia de la lectura porque los verdaderos tecnófilos tienen que saber exactamente qué es lo que hacen en cada momento sin que ninguna clase de software intente facilitarles la vida encapsulando complejidades. Sobre todo cuando ese software ofrece interfaces gráficos.
En cualquier caso y para que nadie pueda dudar de mi profesionalidad voy a enumerar unos cuantos interfaces gráficos cvs en mayor o menor estado de desarrollo:

• pharmacy
• gcvs
• tkcvs, para unix y windows y que además saca un bonito grafo con el historial de desarrollo.
• Tortoise, para windows, integrado en el gestor de ficheros.
• wincvs, para windows, como bien sugiere el nombre. He oído hablar mal de él, pero como no lo he probado no puedo asegurar nada.
• cervisia, para KDE.
• lincvs

Bueno, ya me aburrí. para encontrar los enlaces que faltan, la mayoría aparecerán en http://freshmeat.net y con el tiempo tal vez aparezcan nuevas herramientas.

Otros recursos cvs interesantes

• La página principal que creo que ahora está en http://www.cvshome.org/.
• cvsq, una utilidad para trabajar sin conexión permanente a la red: http://freshmeat.net/news/2000/07/02/962595201.html.
• Enlaces a documentación y otros recursos.
• cvs2cl.pl, que es una herramienta para crear ficheros Changelog al estilo GNU y que puede encontrarse en http://www.red-bean.com/cvs2cl/

Otros recursos cvs más avanzados

• cvsadmin es una herramienta para administrar las cuentas de un repositorio.
• cvs-nserver es una reescritura y extensión de cvs para mejorar sus capacidades en red.
• cvsauth sirve para autenticar usuarios sin ejecutar en el servidor cvs como root.