.NET o no .NET, esa es la cuestión

Si has intentando instalar las últimas versiones de QT en Visual Studio habrás visto que la cosa no funciona como debe ya que la biblioteca no compila, fallando en la parte de la construcción de WebKit, que viene a ser el componente para navegación Web de QT (Algo así como el control OCX del IE, pero válido para cualquier plataforma soportada).

Pese a ello, puede resultar muy interesante tener disponible esta plataforma en Visual C++, ya que, aunque la podemos instalar con su IDE nativo, las funcionalidades de éste apenas le llegan a la suela de los zapatos a las del de Microsoft, y no digamos ya las diferencias en cuanto a rendimiento del compilador de Visual C++ frente al de GNU.

Para quien no lo sepa, QT es un Framework escrito en C++ que es capaz de generar ejecutables para Windows, MAC y Linux a partir de un mismo código fuente. Es algo que todavía no he probado a hacer, pero seguro que dentro de poco publico algo por aquí. En un principio QT era un producto de TrollTech, y su licencia era propietaria. Con el tiempo la empresa fue bajando los requisitos y, gracias sobre todo a KDE –un escritorio Linux-, al final salió con licencia doble. Es decir, podías usarlo para hacer programas propietarios pagando una licencia a TrollTech o hacer programas libres sin tener que pagar nada.

Luego TrollTech fue comprada por Nokia, y con la versión 4.4 de la biblioteca, ésta pasó a ser LGPL, lo que quiere decir que se puede hacer cualquier tipo de desarrollo con ella, paguemos o no. En cierta medida es algo lógico ya que Nokia no se dedica a vender QT, sino que usa QT para sus móviles, y una forma de fomentar el desarrollo con esta biblioteca es la de ofrecerla completamente gratuita. De todos modos hay un requisito que pone Nokia, y es que sólo se puede usar la versión de enlace dinámico (con QT metido en varias DLLs) en lugar de enlace estático. Esto no está muy claro en la licencia en sí, pero pregunté y fue la respuesta que me dieron. Además, tampoco es que sea muy viable un ejecutable de 20 megas, por poner un ejemplo.

Obtener QT. El primer paso es bajarnos el SDK de QT, lo que podemos hacer desde aquí: http://qt.nokia.com/downloads. Debemos elegir la versión LGPL/Free y dentro de ella bajarnos el Qt SDK for Open Source C++ development on Windows. Al hacer clic sobre el enlace citado se iniciará automáticamente la descarga de la última versión del SDK.

Integración con Visual Studio. También debemos bajarnos el Visual Studio Add-in, que se integrará en Visual Studio versión estándar o superior (no creo que funcione en la versión Express).

Una vez instalados ambos elementos, tendremos en la carpeta C:\QT una nueva subcarpeta con la versión instalada, que en mi caso es la 2009.03. Esa instalación está completa, es decir, podremos usar el QtCreator para construir nuestros proyectos, y de hecho no hay que hacer nada más si nos conformamos con las herramientas de que nos provee Nokia.

Cuando instalemos una nueva versión, esta quedará en una nueva carpeta también colgando de C:\QT, y parece ser que la idea de Nokia es sacar cuatro versiones al año. Aparte de la fecha, también se lleva un control de versiones. En el caso que nos ocupa, la versión es la 4.5.2.

De este modo podemos mantener diferentes versiones del producto sin problemas, y de hecho incluso el Add-in de Visual Studio entiende eso y podremos compilar para una o para otra según queramos.

Una cosa a tener en cuenta es que la ruta de instalación no puede tener espacios en blanco, si no luego nos fallarán las herramientas, ya sean de Visual Studio como del propio QtCreator.

El siguiente paso es copiar la carpeta C:\QT\2009.03 en C:\QT\2009.03-vc. Yo he adoptado esa filosofía: la carpeta con la coletilla “-vc” es la versión de Visual Studio. Evidementemente podemos hacer esto directamente sobre la carpeta de instalación original, pero si metemos la pata sólo nos quedará desinstalar, borrar la carpeta, y volver a instalar (que tampoco es mala opción).

Si no fuera por los bugs que cito más abajo, sería buena cosa borrar el contenido de las carpetas bin y lib de lo que hemos copiado, aligerando así el espacio ocupado, pero debido a ello si lo hacemos no seremos capaces de compilar QT para Visual Studio.

Este paso que viene ahora es opcional pero recomendable. Yo me he creado un fichero .bat en C:\QT que he llamado “configure.bat” y que contiene lo siguiente:

cd %1\qt
configure –shared –debug-and-release
nmake

El proceso normal para recompilar QT es ir a la carpeta C:\QT\<versión>\qt y ejecutar el programa configure (en Windows, en Linux configure es un script) con las opciones de comandos adecuadas. En general no es necesaria ninguna excepto la última si queremos que nos construya las versiones debug y release en lugar de sólo la debug.

Con el fichero .bat lo que hago es automatizar este proceso, de modo que sólo tengo que irme a C:\QT y picar “configure <carpeta>” para reconstruir la versión que me interese.

Nos hayamos creado o no el fichero .bat, ahora tenemos que abrir una ventana de comandos de Visual Studio, situada generalmente en Inicio -> All programs -> Visual Studio 2008 -> Visual Studio Tools -> Visual Studio 2008 Command Prompt.

Pero hay truco. Si queremos construir una versión de 64 bits, debemos elegir la consola de 64 bits, y si queremos un sistema de 32, la normal. Deciros que yo todavía no he construido nunca una versión x64, pero por lo que dicen funciona igual de bien que la otra. Sólo con el tipo de ventana el script de QT sabrá qué versión compilar.

Una vez que hemos abierto la ventana de comandos, nos vamos a C:\QT si tenemos el fichero .bat o a C:\QT\<versión>\qt si no lo tenemos.

En el primer caso picamos “configure 2009.03-vc”. En el segundo, “configure –shared –debug-and-release”. En ambos casos nos preguntará qué versión queremos. Tecleamos ‘o’ de OpenSource, y luego ‘y’ para aceptar la licencia correspondiente. A partir de ahí podemos irnos a comer, cenar o echar la siesta.

Si no hubiera bugs en el proceso de compilación, en el primer caso el proceso se realizaría por completo, pero como los hay nuestra compilación se interrumpirá miserablemente. En el segundo caso, una vez que configure haya terminado, debemos teclear “nmake”, cosa que podemos hacer sin que el proceso de configurar haya acabado, y así casi mimetizamos ambos procesos.

Cuando se interrumpa la compilación, tendremos un error del enlazador diciéndonos que faltan una serie de símbolos. Tenemos entonces que irnos a la carpeta C:\QT\<versión>\qt\src\3rdparty\webkit\WebCore\tmp\moc. Ahí veremos dos carpetas, release_shared y debug_shared. Entramos en la primera y borramos el fichero “mocinclude.tmp”. Copiamos el fichero “moc_QnetworkReplyHandler.cpp” y nos vamos a la otra carpeta, debug_shared, en donde volveremos a borrar “mocinclude.tmp” y pegaremos el fichero. Si nos fijamos en esta carpeta hay ya un fichero con ese nombre pero de tamaño cero.

Es conveniente, aunque no obligatorio, “tocar” el fichero “moc_QnetworkReplyHandler.cpp” de debug_shared para que sea posterior a la fecha de creación (yo lo que hago es abrirlo con el bloc de notas, añado y quito un espacio en blanco y lo guardo, así se cambian las fechas.

Ahora volvemos a nuestra consola y volvemos a picar “nmake”. El proceso de compilación seguirá hasta el final, por lo que de nuevo podemos volver a echarnos otra siesta, irnos de parranda o leernos un par de libros. Compilar QT es una tarea larga, incluso en un Quad con 8 GB de memoria.

Borrar “mocinclude.tmp” es necesario para eliminar una caché que impide que el compilador vea los cambios que hemos hecho, por lo que si sólo copiamos el fichero y seguimos con la ejecución del proceso de compilación seguiremos teniendo el error.

El motivo de por qué el otro fichero tiene tamaño cero es harina de otro costal. QT utiliza un metacompilador llamado “moc” para unir los slots con las signals, por lo que el fichero fuente que hemos creado y que contiene elementos de acceso a la UI no vale directamente, primero hay que pasarlo por el programa “moc”, que creará un nuevo fichero ya válido.

En el caso que nos ocupa, el fichero original es “QnetworkReplyHandler.h”, pero por el motivo que sea (todo indica que es un bug del programa “moc”), éste es incapaz de generar el equivalente .cpp procesado para una build debug. Si se mocquea a mano con todas las opciones adecuadas, dice que no encuentra una clase válida y genera un fichero vacío. Hasta ahí he llegado yo.

Lo más curioso de todo es que si borramos los ficheros .a (que son de linux), los lib, los exe y las dll, el proceso de compilación se produce de forma diferente y no se nos crean los ficheros adecuados en la carpeta tmp\moc, de modo que no tenemos forma de copiar de la parte release a la parte debug… Ciertamente resulta algo extraño y mosqueante, y quizás cuando tenga tiempo y ganas lo investigue más a fondo.

Ya hemos compilado QT. Ahora abrimos Visual Studio y abrimos en la barra de menús QT -> QT Options, con lo que obtendremos un cuadro de diálogo en el que añadiremos nuestra nueva versión. Aquí la primera vez debe aparecer vacío, así que hacemos clic en el botón “Add”. Se nos vuelve a abrir otro diálogo y hacemos clic en los puntos suspensivos que hay a la derecha del campo “Path”. Ahora navegamos hasta C:\QT\2009.03-vc\qt y aceptamos. Ahora podemos darle un nombre a esta versión en el campo “Version Name”, por ejemplo “qt-2009.03”. Aceptamos todo y listo, ya tenemos lista la integración.

Si os habéis dado cuenta en el diálogo de opciones, es posible mantener varias versiones de QT y seleccionar la que nos interese por defecto. En principio puede parecer una chorrada, pero cuando tienes aplicaciones legadas con versiones antiguas que no compilan en versiones nuevas de QT es una gran cosa.

Con la integración con Visual Studio tenemos hasta un asistente de proyecto. Si elegimos crear un proyecto nuevo desde la página de inicio o desde el menú normal, veremos que ahora disponemos de un nuevo tipo de proyecto llamado “QT4 Projects” y que nos permite elegir entre diferentes opciones. La normal será “QT Application”, y dentro del asistente podremos elegir qué modulos vamos a usar. Una vez creado un proyecto, si hacemos doble clic sobre un fichero .ui, se nos abrirá el QT Creator, que es un editor visual de formularios y con el que podremos crear nuestras interfaces gráficas igual que se hace en C++Builder, C# o VB.