Creación de tipos de proyecto comunes

Este capítulo describe cómo configurar archivos de proyecto qmake para tres tipos de proyecto comunes que se basan en Qt: aplicación, biblioteca y plugin. Aunque todos los tipos de proyecto utilizan muchas de las mismas variables, cada uno de ellos utiliza variables específicas del proyecto para personalizar los archivos de salida.

Las variables específicas de la plataforma no se describen aquí. Para más información, ver Qt para Windows - Despliegue y Qt para macOS.

Construir una aplicación

La plantilla app le indica a qmake que genere un Makefile que construya una aplicación. Con esta plantilla, el tipo de aplicación se puede especificar añadiendo una de las siguientes opciones a la definición de la variable CONFIG:

Cuando se utiliza esta plantilla, se reconocen las siguientes variables de sistema qmake. Deberías usarlas en tu archivo .pro para especificar información sobre tu aplicación. Para variables de sistema adicionales dependientes de la plataforma, puedes echar un vistazo a las Notas de Plataforma.

• HEADERS - Una lista de archivos de cabecera para la aplicación.
• SOURCES - Una lista de archivos fuente C++ para la aplicación.
• FORMS - Una lista de archivos de interfaz de usuario para la aplicación (creada usando Qt Widgets Designer).
• LEXSOURCES - Una lista de archivos fuente Lex para la aplicación.
• YACCSOURCES - Una lista de archivos fuente Yacc para la aplicación.
• TARGET - Nombre del ejecutable de la aplicación. Por defecto es el nombre del archivo del proyecto. (La extensión, si existe, se añade automáticamente).
• DESTDIR - El directorio en el que se coloca el ejecutable de destino.
• DEFINES - Una lista de las definiciones adicionales del preprocesador necesarias para la aplicación.
• INCLUDEPATH - Una lista de cualquier ruta de inclusión adicional necesaria para la aplicación.
• DEPENDPATH - La ruta de búsqueda de dependencias para la aplicación.
• VPATH - La ruta de búsqueda para encontrar los archivos suministrados.
• ARCHIVO_DEF - Sólo para Windows: Un archivo .def con el que enlazar la aplicación.

Sólo necesita utilizar las variables de sistema para las que tiene valores. Por ejemplo, si usted no tiene ningún INCLUDEPATHs extra entonces usted no necesita especificar ninguna. qmake añadirá los valores por defecto necesarios. Un ejemplo de archivo de proyecto podría tener este aspecto:

TEMPLATE = app
DESTDIR  = c:/helloapp
HEADERS += hello.h
SOURCES += hello.cpp
SOURCES += main.cpp
DEFINES += USE_MY_STUFF
CONFIG  += release

Para los elementos que tienen un solo valor, como la plantilla o el directorio de destino, utilizamos "="; pero para los elementos multivaluados utilizamos "+=" para añadirlos a los elementos existentes de ese tipo. El uso de "=" sustituye el valor de la variable por el nuevo valor. Por ejemplo, si escribimos DEFINES=USE_MY_STUFF, se borrarán todas las demás definiciones.

Creación de un testcase

Un proyecto testcase es un proyecto app destinado a ser ejecutado como una prueba automatizada. Cualquier app puede marcarse como testcase añadiendo el valor testcase a la variable CONFIG.

Para los proyectos testcase, qmake insertará un objetivo check en el Makefile generado. Este objetivo ejecutará la aplicación. Se considera que la prueba pasa si termina con un código de salida igual a cero.

El objetivo check recorre automáticamente los proyectos SUBDIRS. Esto significa que es posible emitir un comando make check desde un proyecto SUBDIRS para ejecutar un conjunto de pruebas completo.

La ejecución del objetivo check puede personalizarse mediante ciertas variables del Makefile. Estas variables son

# Run tests through test-wrapper and use JUnit XML output format.
# In this example, test-wrapper is a fictional wrapper script which terminates
# a test if it does not complete within the amount of seconds set by "--timeout".
# The "-o result.xml,junitxml" options are interpreted by QTestLib.
make check TESTRUNNER="test-wrapper --timeout 120" TESTARGS="-o result.xml,junitxml"

Los proyectos de testcase pueden personalizarse aún más con las siguientes opciones de CONFIG:

Los casos de prueba se escribirán a menudo con QTest o TestCase, pero no es un requisito hacer uso de CONFIG+=testcase y make check. El único requisito principal es que el programa de prueba salga con un código de salida cero en caso de éxito y con un código de salida distinto de cero en caso de fallo.

Creación de una biblioteca

La plantilla lib indica a qmake que genere un Makefile que construya una biblioteca. Cuando se utiliza esta plantilla, se soporta la variable VERSION, además de las variables de sistema que soporta la plantilla app. Utilice las variables en su archivo .pro para especificar información sobre la biblioteca.

Cuando se utiliza la plantilla lib, se pueden añadir las siguientes opciones a la variable CONFIG para determinar el tipo de biblioteca que se construye:

También se puede definir la siguiente opción para proporcionar información adicional sobre la biblioteca.

• VERSION - El número de versión de la biblioteca de destino. Por ejemplo, 2.3.1.

El nombre del archivo de destino de la biblioteca depende de la plataforma. Por ejemplo, en X11, macOS e iOS, el nombre de la biblioteca irá precedido de lib. En Windows, no se añade ningún prefijo al nombre del archivo.

Creación de un plugin

Los plugins se construyen utilizando la plantilla lib, como se describe en la sección anterior. Esto le dice a qmake que genere un Makefile para el proyecto que construirá un plugin en una forma adecuada para cada plataforma, normalmente en forma de librería. Al igual que con las bibliotecas ordinarias, la variable VERSION se utiliza para especificar información sobre el plugin.

• VERSION - El número de versión de la biblioteca de destino. Por ejemplo, 2.3.1.

Creación de un plugin de diseño Qt Widgets

Qt Widgets Los plugins Designer se construyen utilizando un conjunto específico de ajustes de configuración que dependen de la forma en que Qt fue configurado para su sistema. Para mayor comodidad, estos ajustes pueden activarse añadiendo designer a la variable QT. Por ejemplo:

QT          += widgets designer

Ver Qt Widgets Designer Examples para más ejemplos de proyectos basados en plugins.

Compilación e instalación en los modos Debug y Release

A veces, es necesario construir un proyecto tanto en modo debug como release. Aunque la variable CONFIG puede contener las opciones debug y release, sólo se aplica la última opción especificada.

Construcción en ambos modos

Para permitir que un proyecto se construya en ambos modos, debe añadir la opción debug_and_release a la variable CONFIG:

CONFIG += debug_and_release

CONFIG(debug, debug|release) {
    TARGET = debug_binary
} else {
    TARGET = release_binary
}

El ámbito del fragmento anterior modifica el objetivo de compilación en cada modo para garantizar que los objetivos resultantes tengan nombres diferentes. Proporcionar diferentes nombres para los objetivos asegura que uno no sobrescribirá el otro.

Cuando qmake procesa el archivo del proyecto, generará una regla Makefile para permitir que el proyecto se construya en ambos modos. Esto puede ser invocado de la siguiente manera:

make all

La opción build_all se puede añadir a la variable CONFIG en el archivo de proyecto para asegurar que el proyecto se construye en ambos modos por defecto:

CONFIG += build_all

Esto permite que el Makefile sea procesado usando la regla por defecto:

make

Instalar en ambos modos

La opción build_all también asegura que ambas versiones del objetivo serán instaladas cuando la regla de instalación sea invocada:

make install

Es posible personalizar los nombres de los objetivos de compilación en función de la plataforma de destino. Por ejemplo, una librería o plugin puede ser nombrado usando una convención diferente en Windows de la usada en plataformas Unix:

CONFIG(debug, debug|release) {
    mac: TARGET = $$join(TARGET,,,_debug)
    win32: TARGET = $$join(TARGET,,d)
}

El comportamiento predeterminado en el fragmento anterior es modificar el nombre utilizado para el objetivo de compilación cuando se compila en modo de depuración. Se podría añadir una cláusula else al ámbito para hacer lo mismo en modo release. Si se deja como está, el nombre del objetivo no se modifica.