En los títulos y los textos vais a encontrar unas cuantas citaciones cinematográficas (y si, soy un cinéfilo). Si no os interesan podéis fingir no verlas, ya que no son fundamentales para la comprensión de los post...

Este blog es la versión en Español de mi blog en Italiano L'arte della programmazione in C. Espero que mis traducciones sean comprensibles...

sábado, 18 de febrero de 2017

Toma el makefile y corre
cómo escribir un makefile universal

Este es un post rápido. Y no es exactamente un post sobre el C. El consejo es tomar la información, huir y mantenerla celosamente para el futuro, ya que podría ser muy útil un dia. Y que no os capturen, de lo contrario pueden acabar como Virgil Starkwell.

cara de "pero he solo rubato un makefile..."
Así, supongamos que tenemos que hacer un proyecto (que llamaremos, por ejemplo, pluto) y, por diversas razones, no queremos (somos de la vieja escuela) o no podemos (no hay uno adapto) utilizar un IDE. Organizamos nuestros file de una manera clásica, en tres directory: pluto, lib y include. Obviamente escribiremos el código en C y colocaremos los file de una manera lógica (obviamente el file con el main() irá en la directory pluto). Los file son muchos, y cada vez que volvemos a compilar no quieremos reescribir el comando manualmente, y queremos volver a compilar sólo lo que lo necesita (sólo los fuentes modificados) satisfaciendo de forma automática las dependencias de los header (re-compilar sólo aquellos fuentes que dependen de un header modificado)... ¡Entonces nos necesita un makefile! Ok, vosotros ya sabéis lo que es un makefile, pero... ¿ya sabéis escribir uno muy simple y, al mismo tiempo, muy funcional y, sobre todo, genérico y universal? Si la respuesta es NO esto es el vuestro post (y si la respuesta es SI, entonces ¡Hasta el próximo post!).

Acabamos con las chácharas: si estáis leyendo esta línea habéis respondido NO a la pregunta anterior, ¡entonces vamos con el ejemplo!
# variables
CC = gcc
SRCS = $(wildcard *.c)
SRCS_LIB = $(wildcard ../lib/*.c)
OBJS = $(SRCS:.c=.o)
OBJS_LIB = $(SRCS_LIB:.c=.o)
DEPS = $(SRCS:.c=.d)
DEPS_LIB = $(SRCS_LIB:.c=.d)

# creación del target file ejecutable
pluto: $(OBJS) $(OBJS_LIB)
    $(CC) $^ -o $@ -lcurl

# creación de los object files
%.o: %.c
    $(CC) -MMD -MP -I../include -c $< -o $@ -g -Wall -std=c11 -D SIMULATION

# directivas phony
.PHONY: clean

# limpieza proyecto ($(RM) es de default "rm -f")
clean:
    $(RM) $(OBJS) $(OBJS_LIB) $(DEPS) $(DEPS_LIB)

# creación dependencias
    -include $(DEPS) $(DEPS_LIB)
Como se ve el makefile enseñado es verdaderamente simple. Pero también es muy completo: hace todo lo necesario, incluyendo la generación de los files de dependencia de los header, y podemos utilizarlo para cualquier proyecto, sin importar el número de file (las directory lib e include pueden estar vacías o contener cientos de file). Podemos agregar y eliminar fuentes y header y re-compilar sin cambiar una sola línea del makefile, porque el se adapta automáticamente a lo que encuentra en las tres directory del proyecto: ¿Qué queremos más?

Algunos pequeños detalles sobre los bloques (comentados) que componen el makefile:

# variables
Aquí se ponen las variables que se utilizan en el resto del makefile. En particular, la variable CC indica que compilador utilizar: en nuestro caso es gcc, pero podría ser, por ejemplo, g++ (para C++). Obviamente, en este caso las fuentes serían .cpp o .cc, por lo que hay que acordarse de modificar las otras variables que hacen referencia a los .c.

# creacion del target file ejecutable
Aquí se pone el comando para linkar los file objeto creados y producir el file ejecutable final. Si utilizamos laguna librería externa la referencia se añade aquí (en el ejemplo se linka la libcurl usando -lcurl).

# creacion de los object files
Aquí se pone el comando para compilar cada fuente y crear el file objeto correspondiente, activando todas las opciones del compilador que necesitamos. Si utilizamos alguna #ifdef especial (como las que hemos visto alli) la activación hay que ponerla aquí (en el ejemplo se activa una define SIMULATION utilizada en las fuentes).

# directivas phony
Aquí se ponen las directivas phony (es un poco largo de explicar: mirar en el link, que está muy claro). 

# limpieza proyecto ($(RM) es de default "rm -f")
Aquí se pone el comando de borrado de los objetos para forzar, eventualmente, una siguiente completa re-compilación.

# creacion dependencias
Aquí se pone el comando para generar los file de dependencia que nos permiten volver a compilar sólo lo que necesita cuando se modifica un header file. 

El makefile enseñado es un ejemplo real, listo para su uso. Obviamente las directivas -lcurl y -D SIMULATION se han añadido como ejemplo para mostrar cómo extender las funcionalidades del makefile: si no las necesitamos las podemos eliminar sin problemas (y añadiremos las que necesitamos utilizando la misma sintaxis).

¿Qué pensáis? El objetivo no era explicar lo que es un makefile y cómo se escribe (uh, hay una enorme documentación en la red sobre el tema). Tampoco era para explicar los secretos de la sintaxis (que permite también soluciones complejas). El objetivo era proporcionar un makefile básico y completo al mismo tiempo, un makefile universal para (casi) cualquier proyecto. Yo diría que el objetivo se ha logrado... luego, si tenemos que hacer proyectos complejos y portátiles, con auto-instaladores, etc. tal vez nos vamos a encontrar más cómodos usando un IDE de buena calidad o usando herramientas manuales como Autotools  o CMake... pero os aseguro que el método rápido y de la vieja escuela que he descrito es utilizable siempre y sin limitaciones. Que alivio...

¡Hasta el próximo post!

sábado, 14 de enero de 2017

Por un puñado de ifdef
cómo usar el preprocesador en C

Después de la juerga de Año Nuevo es mejor empezar con un post ligero. Hablaremos, entonces del preprocesador... bueno, en realidad si hablasimos del preprocesador en profundidad no sería un post muy ligero, por lo que nos limitaremos a un caso simple, es decir un uso interesante de la directiva #ifdef. Y os sugiero de seguir los consejos de Joe (el extranjero), ya que es uno que se enfada fácilmente...
...y quién no utiliza el #ifdef tendrá que tratar conmigo...
Por lo tanto: retomamos un viejo pedazo de código que se muestra aquí (en seguida a releerlo!), el del Socket Server. Asumiendo que tengáis muy claro cómo funciona, lo vamos a modificar siguiend un posible caso real, que sería el siguiente: supongamos que tenemos que compilar el nuestro código para dos entornos operativos diferentes, por ejemplo para un Linux Desktop/Server reciente, y para Linux Embedded  un poco anticuado (con compilador, kernel y glibc de hace unos años). Hemos decidido por diversas razones que el nuevo código tiene que crear un socket no bloqueante en la fase de accept, así que por ejemplo, se podría reemplazar la llamada a accept() con una a accept4() que tiene un argumento flags que se puede establecer a SOCK_NONBLOCK que es justo lo que necesitamos. Por desgracia, nuestro sistema embedded (anticuado, como se ha mencionado) utiliza un kernel más antiguo del 2.6.28 y una glibc anterior a la 2,10 (que son las dos condiciones mínimas para poder utilizar la accept4()). ¿Qué hacer? Hacemos dos versiones del código? ¡NO! ¿Por qué así tendremos que hacer  (en el futuro) doble mantenimiento, que es una situación a evitar. Vamos a mantener, sin embargo, sólo una versión con las #ifdef apropiadas para gestionar la compilación en los dos entornos operativos.

Entonces, el fragmento de código (extracto de ese post allí) que hay que cambiar es el siguiente: 
... 
// acepta conexiones de un client entrante
printf("%s: espera connexiones entrantes...\n", argv[0]);
socklen_t socksize = sizeof(struct sockaddr_in);
struct sockaddr_in client;          // (remote) client socket info
int client_sock;
if ((client_sock = accept(my_socket, (struct sockaddr *)&client, &socksize)) < 0) {
    // error accept()
    printf("%s: accept failed (%s)\n", argv[0], strerror(errno));
    return EXIT_FAILURE;
}
...
Y la nueva versión con la compilación condicional a través de #ifdef será la siguiente:
...
// acepta conexiones de un client entrante (en non blocking mode: my_socket es SOCK_NONBLOCK)
printf("%s: espera connexiones entrantes...\n", argv[0]);
socklen_t socksize = sizeof(struct sockaddr_in);
struct sockaddr_in client;          // (remote) client socket info
int client_sock;
#ifdef OLD_LINUX
if ((client_sock = accept(my_socket, (struct sockaddr *)&client, &socksize)) < 0) {
#else
if ((client_sock = accept4(my_socket, (struct sockaddr *)&client, &socksize, SOCK_NONBLOCK)) < 0) {
#endif
    // error accept()
    printf("%s: accept failed (%s)\n", argv[0], strerror(errno));
    return EXIT_FAILURE;
}
#ifdef OLD_LINUX
else {
    // accept ejecutada: set socket a non-blocking
    int flags;
    if ((flags = fcntl(client_sock, F_GETFL, 0)) >= 0) {
        if (fcntl(client_sock, F_SETFL, flags | O_NONBLOCK) < 0) {
            // error accept()
            printf("%s: fcntl failed (%s)\n", argv[0], strerror(errno));
            return EXIT_FAILURE;
        }
    }
}
#endif
...
Ok, como se nota es ampliamente comentado y así se auto-explica, por lo cual no voy a detenerme sobre las instrucciones y/o grupos de instrucciones (¡leer los comentarios! ¡Están ahí para eso!), pero voy a añadir, solamente, algunos detalles estructurales.

En las partes incluidas en el #ifdef OLD_LINUX hay la versión del código que NO utiliza la accept4(), y que es, obviamente, un poco más complicada que la otra, porque hay que utilizar fcntl() para transformar en no-bloqueante el socket creado, mientras que la accept4() lo crea directamente usando, como se ha mencionado, el flag SOCK_NONBLOCK. Sin embargo, como se puede ver, el código resultante es bastante claro y legible y, después de todo, no se ve tan mal (¡el estilo primero!).

Alguien podría decir: la versión bajo #ifdef también trabaja con un Linux reciente, así que ¿por qué no dejar solo esa y quitar las #ifdef? ¡NO! ¡NO! y otra vez ¡NO! No hay que escribir código old-style para que sea retro-compatible: siempre hay que tratar de escribir de una manera moderna, y si es necesario (como en el ejemplo) hay que poner el material antiguo bajo #ifdef. Y cuando llegue el momento (cuando, por ejemplo, ya no vamos a usar un entorno operativo dual) limpiaremos y dejaremos sólo un bonito código moderno.

Obviamente la compilación condicional la efectuaremos mediante la introducción (o no introducción) de una instrucción -D OLD_LINUX  en la línea del nuestro makefile que genera lo files objeto, o directamente en la línea de comandos si no se utiliza un makefile. Bueno, por fin hemos escribito un código único para dos entornos operativos diferentes: ¡misión cumplida!

Sólo una última aclaración sobre el nuestro socket server modificado (y que no tiene nada que ver con las #ifdef): si el non-blocking socket nos necesita para ejecutar unas recv() no bloqueantes en la siguiente fase a la de accept, es mucho más fácil modificar adecuadamente el loop de recepción y pasar el flag MSG_DONTWAIT a la recv() en el argumento flags (el cuarto). Por lo que la recv() no bloquea en ambos entornos operativos, y todo ello sin el uso de #ifdef. Pero esa es otra historia...

¡Hasta el próximo post!