SDK Multiplataforma en C logo

SDK Multiplataforma en C

Portabilidad

❮ Anterior
Siguiente ❯

Es muy difícil escribir software que funcione correctamente y de manera eficiente. Entonces, una vez que un programa funciona en un determinado entorno, no queremos repetir parte del trabajo al moverlo a un compilador, procesador o sistema operativo diferente. Idealmente, no debería ser necesario realizar ningún cambio en absoluto. Kernighan & Pike - The Practice of Programming.


En Inicio rápido y Nuevo proyecto utilizamos Visual Studio 2019 para generar la solución NAppGUI. Entendemos por portabilidad la capacidad de compilar y depurar nuestros programas en otras plataformas diferentes a las que fueron escritos, sin que por ello tengamos que tocar ni una sola línea de código. Entendemos por plataforma a la combinación de un compilador y de una arquitectura CPU. Por ejemplo, v142_x64 hace referencia a Visual Studio 2019 e Intel 64bits. En (Figura 1) vemos los diferentes pasos en el proceso de migración de código.

Tres ordenadores Windows, macOS y Linux conectados en red al mismo repositorio de código fuente.
Figura 1: Etapas en la portabilidad del código entre plataformas.
  • Copia de trabajo: En cada máquina deberá existir una copia del código fuente del proyecto. Normalmente esto se llevará a cabo mediante un sistema de control de versiones como Subversion o Git, aunque se podría actualizar también desde una memoria externa.
  • CMake: CMake creará un proyecto de compilación (o solución) a partir del código fuente utilizando los scripts del directorio /prj de la distribución del SDK. Esto se realizará de forma totalmente automática.
  • Compilar: Utilizando Visual Studio, Xcode o GCC se compilará la solución y se generarán las librerías y ejecutables incluidos en la misma.
  • Ejecutar/Depurar: Los binarios ya se podrán ejecutar y depurar en la plataforma de destino.

1. Portabilidad Windows

Podemos utilizar cualquier versión de Visual Studio a partir de 2005 para compilar bajo Windows (Tabla 1). Como ya vimos en Inicio rápido lo primero que tenemos que hacer es lanzar CMake sobre el código fuente:

Tabla 1: Versiones de Visual Studio soportadas por NAppGUI.
Compilador Plataforma S.O.Mínimo
Visual Studio 2019 v142_x64 (x86) Vista
Visual Studio 2017 v141_x64 (x86) Vista
Visual Studio 2015 v140_x64 (x86) Vista
Visual Studio 2013 v120_x64 (x86) Vista
Visual Studio 2012 v110_x64 (x86) Vista
Visual Studio 2010 v100_x64 (x86) XP
Visual Studio 2008 v90_x64 (x86) XP
Visual Studio 2005 v80_x64 (x86) XP
  • Where is the source code: C:\nappgui\src.
  • Where to build the binaries: C:\nappgui_build.
  • Pulsamos [Configure] y [Generate].

La primera vez CMake preguntará que versión de Visual Studio queremos utilizar (Figura 2) y que, obviamente, deberemos tener instalada. La arquitectura seleccionada por defecto se puede cambiar desde el mismo diálogo (Figura 3).

Desplegable que muestra las diferentes versiones de Visual Studio con las que podemos compilar.
Figura 2: Selección de la versión de Visual Studio desde el asistente de CMake.
CMake Optional platform for generator.
Figura 3: Selección de la arquitectura en el panel del generador.

Una vez pulsemos [Open Project], tendremos el proyecto listo para compilar. Desde Visual Studio Build->Build Solution y depuramos Debug->Start Debugging (Figura 4).

Visual Studio 2010 depurando una aplicación C.
Figura 4: Depurando la aplicación Die en Visual Studio 2010.
Para cambiar la versión de Visual Studio tenemos que borrar la cache de CMake File->Delete Cache o cambiar el directorio de destino: Where to build the binaries. Es posible tener diferentes soluciones a partir del mismo código en varios directorios, cada una con su propia versión de Visual Studio.

A partir de Visual Studio 2010, se produce una disociación entre el editor y el compilador. El término Plaform Toolset identifica al propio compilador, que se podrá seguir utilizando con IDEs mas modernos. Si no indicamos nada, CMake utilizará el toolset incluido por defecto en cada versión de VS, pero se puede cambiar desde Optional toolset to use. Por ejemplo, podemos combinar Visual Studio 15 2017 con el toolset de VS2013 v120_xp (Figura 5).

Opción Optional toolset to use de CMake.
Figura 5: Uso del toolset v120_xp con el editor de VS2017.

1.1. Visual C++ Redistributable

Por defecto, Visual Studio enlaza dinámicamente las funciones de la librería de C, lo que provoca que los .exe puedan no funcionar en máquinas que no dispongan de las DLL de VC++ (Figura 6). Esto obliga a las aplicaciones a incluir una copia de MSVCRT.dll, VCRUNTIME.dll, ... o a instalar los famosos paquetes Visual C++ Redistributable para asegurar que la aplicación pueda correr sin problemas.

Mensaje de error provocado por la falta de las librerías de VC++.
Figura 6: Error por la falta de las .dll de VC++.

NAppGUI utiliza un reducido conjunto de la librería C, ya accede directamente al API de Windows siempre que sea posible (más detalles en Librería estándar de C). Por esta razón, todas las aplicaciones creadas con NAppGUI realizan un enlace estático (opción /MT) de las funciones que necesitan de la stdlib, evitando dependencias a costa de aumentar ligeramente (unos pocos Kb) el tamaño del ejecutable final. Esto garantiza que las aplicaciones correrán sin problemas en todas las máquinas Windows sin necesidad de DLLs adicionales y sin tener que instalar los VC++ Redistributable.

Las aplicaciones NAppGUI no requieren los Visual C++ Redistributable. Tampoco utilizan las MFC "Microsoft Foundation Classes" ni la plataforma .NET.

1.2. Soporte WindowsXP

A partir de VS2012, el Platform Toolset genera ejecutables no compatibles con WindowsXP. Si queremos que nuestras aplicaciones corran en este sistema, deberemos seleccionar el toolset alternativo acabado en _xp: V141_xp, V140_xp, V120_xp, V110_xp. O bien, v100, v90 ó v80, que sí soportan XP (Figura 7).

El soporte para WindowsXP se ha eliminado definitivamente en Visual Studio 2019. No existe el Platform Toolset v142_xp.
Uso de Visual Studio 2005 en WindowsXP depurando una aplicación escrita en C.
Figura 7: Depurando la aplicación Die en WindowsXP con VS2005 (toolset v80).
NAppGUI no funciona en Windows anterior a XP ni con Visual Studio anterior a 2005.

1.3. Soporte SSE

Con el Pentium III, Intel incorporó un juego de instrucciones adicional para operaciones en coma flotante denominado SSE Streaming SIMD Extensions. Esto permite optimizar los cálculos matemáticos a costa de perder la compatibilidad, ya que las aplicaciones que utilicen SSE no funcionarán en los modelos Pentium II o anteriores. En NAppGUI se han reservado los toolset v80_x86 y v90_x86 para crear aplicaciones compatibles con los procesadores más antiguos (Tabla 2). A partir de v100_x86, se utilizará SSE2 en todos los toolset.

Tabla 2: Soporte SSE
Toolset SSE CPU Mínima
v80_x86 x87 (no SSE) Pentium II/AMD K6
v90_x86 SSE Pentium III/AMD Duron
v100_x86 SSE2 Pentium IV/AMD Sempron
v110_x86 SSE2 Pentium IV/AMD Sempron
... SSE2 ...
El soporte SSE solo se deshabilita en arquitecturas de 32 bits (x86). Todas las CPU de 64 bits (x64) incorporan SSE2.

2. Portabilidad macOS

Compilar para los iMac, macBook y macMini de Apple sigue la misma filosofía vista anteriormente, tan solo necesitaremos CMake y Xcode a partir de la versión 3.2.6 (Tabla 3). Al igual que hicimos en Windows, abrimos CMake y asignamos los directorios:

Tabla 3: Versiones de Xcode soportadas por NAppGUI.
Compilador Plataforma S.O.Mínimo
Xcode 12.2 sdk11_00_x64 (arm) Big Sur
Xcode 11.7 sdk10_15_x64 Catalina
Xcode 10.3 sdk10_14_x64 Mojave
Xcode 9.4.1 sdk10_13_x64 High Sierra
Xcode 8.3.3 sdk10_12_x64 Sierra
Xcode 7.3.1 sdk10_11_x64 El Capitan
Xcode 6.4 sdk10_10_x64 Yosemite
Xcode 6.2 sdk10_9_x64 Mavericks
Xcode 5.1.1 sdk10_8_x64 Mountain Lion
Xcode 4.6.3 sdk10_7_x64 Lion
Xcode 3.2.6 sdk10_6_x64 (x86) Snow Leopard
  • Where is the source code: /Users/fran/nappgui/src (o WORKING_DIR/nappgui/src).
  • Where to build the binaries: /Users/fran/nappgui_build. Directorio donde irá a parar el código generado.

Pulsa [Configure]. La primera vez CMake nos pedirá seleccionar el compilador. Al contrario que Visual Studio, solo ofrece una opción para Xcode (Figura 8). Aceptamos, pulsamos [Generate] y después [Open Project].

Seleccionando Xcode desde el asistente de CMake.
Figura 8: Selección del generador Xcode en CMake.

Al abrir la solución Xcode (NAppGUI.xcodeproj), vemos los diferentes proyectos que la forman, incluídos Die y Dice. Seleccionamos Die en el desplegable superior izquierdo y después pulsamos Play o Product->Run (Figura 9). Esto compilará el programa y lo lanzará en modo depuración, donde podremos establecer puntos de ruptura para inspeccionar la pila y el valor de las variables.

Depurando la aplicación Die desde Xcode 10.2.1.
Figura 9: Depurando la aplicación Die en Xcode.

2.1. Base SDK y Deployment Target

Cada año, Apple lanza una nueva versión de macOS, que viene acompañada de un nuevo SDK y de la actualización de Xcode que incluye dicho SDK.

Base SDK es la versión incluída en cada nueva versión mayor de Xcode, que coincide con la última versión del sistema macOS aparecida en el mercado.

Apple tiene una política mucho más restrictiva que Microsoft en lo referente a la compatibilidad de las aplicaciones con versiones anteriores del sistema operativo. Por defecto, un programa compilado con SDK 10.14 (macOS Mojave) no funcionará en el inmediatamente anterior macOS High Sierra (Figura 10).

Error al ejecutar una aplicación con deployment target 10.14 en macOS High Sierra.
Figura 10: Die con Base SDK 10.14 no funcionará en High Sierra.

Para evitar este problema, y que las aplicaciones funcionen en macOS más antiguos, existe el parámetro Deployment Target. Al utilizarlo, se activará una macro que anulará las nuevas características del Base SDK. Esto permitirá que el programa corra en versiones antiguas a costa, claro está, de no tener acceso a las últimas funcionalidades de los iMac. Podrás seleccionar el Deployment Target a través de la lista de opciones de CMake, después de pulsar [Configure] (Figura 11).

Seleccionando el Xcode Deployment Target desde CMake.
Figura 11: Selección del Deployment Target de nuestra solución.
Xcode 8 considera obsoletos los Deployment Target inferiores a 10.9 (Figura 12). Utiliza Xcode 7 si quieres compatibilidad con Mac OSX 10.8 Mountain Lion y anteriores.
Warning osx 10.9 deprecated.
Figura 12: Deployment Target 10.9 obsoleto a partir de Xcode 8.

2.2. Múltiples versiones de Xcode

Ya hemos visto que CMake solo ofrece una opción para Xcode, aunque es posible tener varias versiones en la misma máquina, cada una dentro de su propio bundle Xcode.app. Siempre existirá un Xcode por defecto en el sistema (el más reciente) pero se puede cambiar mediante la utilidad xcode-select:

Listado 1: Consulta de la versión actual de Xcode.
1
2
xcode-select -p
/Applications/Xcode.app/Contents/Developer
Listado 2: Cambio de la versión activa de Xcode.
1
sudo xcode-select -s /Applications/Xcode8.app/Contents/Developer
Listado 3: Establecer la versión por defecto de Xcode.
1
sudo xcode-select -r
Deberás pulsar [Configure] y [Generate] en CMake cada vez que utilices xcode-select para que tu proyecto actualice el cambio de compilador.

2.3. macOS ARM

En Noviembre de 2020 Apple lanza su nueva línea de ordenadores de sobremesa y portátiles (iMac, macBook y macMini) basados en el procesador Apple M1 con arquitectura ARM (Figura 13). A pesar que son capaces de ejecutar programas compilados para Intel x64 mediante el programa Rosetta 2 (Figura 14) lo ideal sería compilar nuestras aplicaciones para la nueva arquitectura con el fin de optimizar al máximo los ejecutables.

Imagen de un procesador Apple M1.
Figura 13: Procesadores M1 de Apple.
Warning Rosetta 2 en un Apple M1.
Figura 14: Aviso Rosetta 2 al intentar ejecutar código x64 en un Apple M1.

NAppGUI soporta la arquitectura Apple ARM mediante el paquete sdk11_00_arm. Tan solo deberás seleccionar la opción arm64 en CMAKE_ARCHITECTURE (Figura 15).

Puedes compilar la arquitectura M1 desde máquinas Intel x64, pero no podrás depurar los ejecutables.
La arquitectura M1 solo está disponible para el sistema Big Sur (macOS 11.0) y posteriores.
CMake opciones para arquitectura M1.
Figura 15: Selección de la arquitectura M1 desde CMake.

2.4. macOS 32bits

Desde la versión macOS High Sierra, Apple ha declarado obsoleta la arquitectura de 32 bits, emitiendo avisos a los usuarios en el caso de detectar ejecutables i386 (Figura 16). A partir de Xcode 10, no se puede compilar en esta arquitectura (Figura 17).

Aviso de macOS al intentar ejecutar aplicaciones de 32bits.
Figura 16: Avisos de macOS en aplicaciones de 32bits.
Mensaje de error en Xcode 10 al compilar en 32bits.
Figura 17: Error en Xcode 10 al intentar compilar en 32bits.
El soporte para aplicaciones 32bits ha desaparecido definitivamente en macOS Catalina, que solo permite ejecutar aplicaciones de 64bits.

Esto tiene cierto sentido ya que todos los modelos de iMac basados en Intel incorporan procesadores de 64 bits, a excepción de unos pocos modelos de 2006 en policarbonato blanco que montaban el Intel Core Duo de 32 bits (Figura 18). Estos iMac admitían como máximo el Mac OSX 10.6 Snow Leopard, siendo requisito fundamental a partir de 10.7 Lion, el disponer de una CPU de 64 bits. Para compilar sin problemas en 32bits hay que utilizar, como máximo, Xcode 6 (Figura 19).

iMac, macBook y macMini con procesadores Intel de 32bits.
Figura 18: Únicos modelos de Apple con procesador Intel de 32bits.
Depurando la aplicación Die desde Xcode en Snow Leopard.
Figura 19: Compilación en 32bits con Xcode 3.2.6 (Snow Leopard).

3. Portabilidad Linux

En el mundo Linux, se utiliza el compilador gcc (Tabla 4) y la herramienta make para generar los binarios, pero no existe un entorno de desarrollo "oficial". Para realizar una configuración elemental de nuestro equipo en Ubuntu teclear los siguientes comandos:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
// Development tools
sudo apt-get install gcc
sudo apt-get install g++
sudo apt-get install make
sudo apt-get install subversion
sudo apt-get install cmake cmake-qt-gui

// Development libraries
sudo apt-get install libgtk-3-dev
sudo apt-get install libglu1-mesa-dev freeglut3-dev mesa-common-dev
sudo apt-get install libcurl4-openssl-dev

// GTK Inspector (Ctrl+D when debugging)
gsettings set org.gtk.Settings.Debug enable-inspector-keybinding true

// Check system libraries version
pkg-config --modversion gtk+-3.0
3.24.20

pkg-config --modversion libcurl
7.68.0
Tabla 4: Versiones de GCC soportadas por NAppGUI.
Compilador Plataforma Toolkit S.O.Mínimo
GCC 9.3 gcc9_gtk3_x64 GTK 3.24.20 Ubuntu 20.04 LTS
GCC 7.5 gcc7_gtk3_x64 GTK 3.22.30 Ubuntu 18.04 LTS
GCC 5.4 gcc5_gtk3_x64 GTK 3.18.9 Ubuntu 16.04 LTS
GCC 4.8.4 gcc4_8_gtk3_x86 GTK 3.10.8 Ubuntu 14.04 LTS
GCC 8.3.0 gcc8_gtk3_arm GTK 3.24.5 Raspbian 10 Buster
GCC 6.3.0 gcc6_gtk3_arm GTK 3.22.11 Raspbian 9.1 Strech

La metodología de trabajo no cambia en absoluto. Abrimos CMake, seleccionamos los directorios, pulsamos [Configure] y después [Generate] (Figura 20).

Configurar los directorios de CMake en Linux.
Figura 20: Configurando NAppGUI en Linux.

En Linux deberemos utilizar el generador Unix Makefiles de CMake, el cual creará una serie de guiones Makefile en /home/fran/nappgui_build (o el directorio de salida que hayamos seleccionado). Estos Makefile contienen los comandos necesarios para compilar y enlazar todos los proyectos de la solución. Abrimos un terminal y ejecutamos make:

Listado 5: Generar la solución mediante make.
1
2
3
4
5
6
7
8
cd /home/fran/nappgui_build
make
[ 15%] Building C object games/die/CMakeFiles/Die.dir/dgui.c.o
[ 30%] Building C object games/die/CMakeFiles/Die.dir/die.c.o
[ 45%] Building C object games/die/CMakeFiles/Die.dir/draw/ddraw.c.o
[ 60%] Building C object games/die/CMakeFiles/Die.dir/resgen/all.c.o
[ 75%] Linking CXX executable Debug/Die
[ 95%] Built target Die

Una vez terminada la compilación, podemos lanzar los ejecutables directamente desde el terminal:

Listado 6: Lanzar la aplicación Die.
1
./die/Debug/Die

Y si somos unos auténticos hackers, seremos capaces de depurar los programas directamente desde gdb (Figura 21).

Listado 7: Depurando Die con gdb
1
2
3
gdb ./die/Debug/Die
(gdb) run
...
Uso de GDB para depurar una aplicación C.
Figura 21: Depurando Die con GDB desde el terminal.

3.1. GTK+3

A diferencia de Windows y macOS, en Linux se pueden crear interfaces de usuario utilizando diferentes librerías (o toolkits) siendo GTK y Qt las dos más famosas. NAppGUI utiliza GTK+3 para la parte gráfica en Linux (ver Dependencias), aunque en un futuro es posible que incorpore también el soporte para Qt, ya que es la base del sistema de escritorio KDE, utilizado en Kubuntu. GTK+3 se encuentra de forma natural en Ubuntu y muchas otras distribuciones, aunque para compilar es necesario instalar la versión de desarrollador, como indicamos al inicio de la sección.

3.2. Múltiples versiones de GCC

Aunque cada distribución de Linux incorpora una versión "canónica" de GCC, es posible tener varias instaladas en la misma máquina y alternar entre ellas de forma similar a como hacíamos en el mac con xcode-select. Para ello utilizaremos el comando update-alternatives de Linux. Suponemos que estamos en Ubuntu 18.04 LTS:

Listado 8: Versión de gcc instalada.
1
2
gcc --version
gcc 7.5.0
Listado 9: Instalar gcc-6
1
sudo apt-get install gcc-6 g++-6
Listado 10: Registrar gcc-7 y gcc-6
1
2
sudo update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-7 60 --slave /usr/bin/g++ g++ /usr/bin/g++-7
sudo update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-6 50 --slave /usr/bin/g++ g++ /usr/bin/g++-6
Listado 11: Cambiar a gcc-6.
1
2
3
4
5
sudo update-alternatives --set gcc /usr/bin/gcc-6
gcc --version
gcc 6.5.0
g++ --version
g++ 6.5.0
Listado 12: Volver a la versión por defecto de gcc.
1
2
3
4
5
sudo update-alternatives --auto gcc
gcc --version
gcc 7.5.0
g++ --version
g++ 7.5.0

3.3. Eclipse CDT

Trabajar directamente con el terminal nos brinda una gran flexibilidad a la hora de configurar nuestras herramientas. Con volver a la consola y teclear make se re-compilará todo lo necesario. Ahora bien, utilizar GDB directamente resultará bastante tedioso, por lo que daremos el salto a Eclipse CDT. Este entorno nos permitirá programar con una metodología similar a la de Visual Studio y Xcode: Situar puntos de ruptura, inspeccionar la pila y variables, buscar archivos dentro del directorio de código, ediciones múltiples, búsquedas masivas, etc.

No es imperativo utilizar Eclipse. Puedes elegir el editor/IDE que prefieras.

La única diferencia es que deberemos utilizar el generador Eclipse CDT4 - Unix Makefiles en CMake (Figura 22) que adicionalmente a los Makefile creará los archivos .cproject y .project necesarios para importar el proyecto dentro de Eclipse.

Generadores CMake para Linux basados en Makefile.
Figura 22: Generadores basados en Makefile.

Abrimos Eclipse y hacemos File->Import->Existing Projects into Workspace. Aparecerá un cuadro de diálogo donde indicamos el directorio build que hayamos configurado en CMake (/home/fran/nappgui_build). Eclipse abrirá el proyecto situando a la izquierda un árbol con todos los archivos y compilaremos con Project->Build All. A la hora de depurar (Die en este caso) crearemos un perfil desde Run->Debug Configurations->C/C++ Application. Pulsamos [Search Project...] y seleccionamos Die en la lista desplegable. Finalmente pulsamos [Debug] para depurar la aplicación de forma interactiva (Figura 23).

Depurando la aplicación Die desde Eclipse.
Figura 23: Depurando la aplicación Die con Eclipse.

Algunas opciones interesantes de Eclipse CDT bajo Window->Preferences.

  • Run/Debug->Launching->Terminate and Relaunch while launching.

3.4. Linux 32bits

Para compilar aplicaciones 32bits desde un sistema Ubuntu 64bits es necesario instalar el paquete multilib:

1
sudo apt-get install gcc-multilib

Pero actualmente existen problemas para realizar compilación cruzada que incluya la librería GTK+, por lo que no será posible utilizar la misma máquina de desarrollo para generar en ambas arquitecturas, como ocurre en Windows. Las aplicaciones de consola o librerías que no accedan a GTK sí que se pueden compilar en 32bits desde un ordenador de 64bits.

No es posible compilar en 32bits desde un sistema Ubuntu de 64bits aplicaciones que utilicen GTK+3.

3.5. Arquitectura ARM

La arquitectura ARM Advanced RISC Machine es la predominante en el mercado de los dispositivos embebidos como teléfonos inteligentes y tablets. Actualmente, NAppGUI no ofrece soporte para el desarrollo de aplicaciones móviles iOS/Android, pero sí para otro tipo de placas que soporten versiones de Linux ARM "de escritorio", como la Raspberry PI con Raspbian. Para portar nuestro código a Raspberry Pi hay que seguir los mismos pasos que en Ubuntu Linux (Figura 24). Ambas distribuciones están basadas en Debian, por lo que disponemos de GCC, CMake y Eclipse de forma directa a través de apt-get.

Depuración de una aplicación C en una Raspberry Pi, utilizando Eclipse.
Figura 24: Depuración de la aplicación Die en una Raspberry Pi.

4. Configuraciones

Una aplicación NAppGUI se puede compilar en tres configuraciones diferentes, en función del nivel de depuración que necesitemos.

  • Debug: Incluye información de depuración en los binarios y no se realizan optimizaciones del código. Es la versión para el desarrollador.
  • Release: Se elimina la información de depuración y se realizan todas las optimizaciones posibles. Es la versión para el usuario.
  • ReleaseWithAssert: Es la versión de Release, pero dejando activas las sentencias Asserts. Está dirigida al usuario final, pero en casos donde sea necesario obtener información detallada de posibles anomalías, a costa de una bajada del rendimiento global del programa.

Tanto Visual Studio como Xcode son entornos multi-configuración, es decir, podemos alternar entre una y otra directamente desde el propio editor. En Visual Studio tenemos un desplegable en la parte superior del editor (Figura 25).

Menú de selección de configuración en Visual Studio.
Figura 25: Cambio de configuración en Visual Studio.

En Xcode está un poco más escondido. Hacemos Product->Scheme->Edit Scheme. Aparecerá una ventana emergente. Seleccionamos Run->Info->Build Configuration (Figura 26).

Menú de selección de configuración en Xcode.
Figura 26: Cambio de configuración en Xcode.

Desafortunadamente, Unix make no soporta múltiples configuraciones. Esto nos obliga a introducir la propiedad CMAKE_BUILD_CONFIG (Figura 27) para establecer la configuración en CMake antes de generar los Makefile. Deberemos volver a pulsar [Configure] y [Generate] para que la nueva configuración surja efecto.

Menú de selección de configuración en CMake.
Figura 27: Cambio de configuración en CMake (Unix Makefile).

5. Instaladores

El último paso, una vez creado y depurado un programa, será el de crear un paquete/instalador que contenga el ejecutable y sus posibles dependencias, para distribuirlo de forma cómoda al usuario final. Este proceso de empaquetado se ha automatizado en NAppGUI gracias a CPack, una utilidad incluida con CMake (Figura 28).

Panel de CMake con las opciones de empaquetado.
Figura 28: Opciones de empaquetado en CMake.
  • Activar la opción CMAKE_PACKAGE en el panel de CMake.
  • Establecer en CMAKE_PACKAGE_PATH el directorio en el que van a guardar los paquetes generados.
  • Seleccionar el tipo de empaquetado a través de la variable CMAKE_PACKAGE_GEN que admite tres valores:
    • TGZ: Crea un paquete comprimido .tar.gz que puede abrirse con cualquier utilidad .zip instalada en el ordenador (Figura 29).
    • Empaquetado de una aplicación con .tar.gz.
      Figura 29: Empaquetado .tar.gz en Linux.
    • DragNDrop: (Solo macOS). Crea una unidad dmg con un bundle .app y un enlace a la carpeta /Applications (Figura 30).
    • Empaquetado de una aplicación en dmg.
      Figura 30: Empaquetado dmg en macOS.
    • NSIS: (Solo Windows). Crea un instalador mediante la utilidad Nullsoft scriptable install system (Figura 31). Es necesario tener instalado el software NSIS (solo para crear el instalador). El usuario que recibe el paquete no es necesario que tenga dicho software instalado.
    • Instalador NSIS con la aplicación que acabamos de crear.
      Figura 31: Instalador NSIS.

Cada paquete incluye una copia de la licencia con la que vamos a distribuir la aplicación. El contenido de la misma podemos editarlo a partir del archivo /res/license.txt incluido en el directorio de recursos de cada proyecto.

El empaquetado de un programa consume tiempo. Activar CMAKE_PACKAGE únicamente cuando vayamos a distribuir. Durante el proceso de desarrollo se aconseja desactivar el checkbox.
❮ Anterior
Siguiente ❯