Qt5 ossia il deployment impossibile su Windows

Ultimamente ho iniziato a pensare, un po’ più seriamente rispetto a qualche tempo fa, di portare le mie applicazioni da Qt4 a Qt5. Mentre immaginavo di fare ciò in un futuro non troppo lontano, sono stato fatalmente anticipato da uno sviluppatore che nel suo tempo libero ha deciso di modificare i sorgenti di Ascii Design e inviarmi le modifiche su GitHub.

Sebbene il tempo libero ultimamente scarseggi, ho deciso di sfruttare un paio di mezz’ore per provare a compilare l’applicazione utilizzando Visual Studio 2012 e Qt5.

Sebbene Visual Studio si sia inizialmente dimostrato un po’ restio nel voler riconoscere la struttura dell’albero dei sorgenti, dopo un paio di modifiche un po’ qua e un po’ là ha deciso finalmente di compilare il binario dell’applicazione.

Devo premettere che, sebbene le Qt5 non siano esattamente una novità e dato che su Linux, anche a causa di Kde, siano tuttora più utilizzate le vecchie Qt4, non mi sono posto l’obiettivo di studiarmi con troppa fretta questa nuova versione del toolkit. Oltre ciò, dato che ultimamente ho avuto una grossa lite con Visual Studio 2010, non ho avuto molta voglia di approfondire il discorso Qt5 su Windows dato che necessitavo di un ambiente di sviluppo funzionante.

A dirla tutta anzi aspettavo che le Qt5 iniziassero ad entrare nel periodo di maggiore diffusione, esattamente come sta succedendo in questo preciso momento, ed iniziare il porting delle mie applicazioni.

Di conseguenza questo che sto narrando è stato esattamente il mio primo impatto con la nuova versione del Qt Framework non solo su Linux ma anche su Windows. Anzi diciamo solo su Windows.

Dato che solitamente il progresso in questi ambiti, almeno dal mio punto di vista, porta sempre dei vantaggi, avevo immaginato che il deployment di un’applicazione su Windows fosse un gioco da ragazzi; ma dopo aver compilato l’applicazione mi sono ricreduto secondo dopo secondo dopo secondo e così via.

Sono venuto infatti a sapere che su Windows, per distribuire la minima applicazione che fa il minimo utilizzo dei moduli Qt (stiamo parlando di QtCore, QtGui), sono necessarie talmente tante dipendenze che per distribuire un binario di quasi 160 Kb sono necessari quasi 40 megabyte di librerie!

È un’assurdità se pensiamo che in Qt4 ne bastavano circa 10 (che oltretutto non sono di certo pochi) per distribuire un’applicazione minima.

L’origine dei mali è da ricercarsi nell’introduzione di ICU come backend di localizzazione. Da quanto ho letto dalle parole dei più esperti, sembrerebbe che ICU, almeno in ambiente Windows, sia una dipendenza non dell’intero framework ma soltanto di QtWebKit, il modulo per il rendering delle pagine web utile a costruire ad esempio i browser o qualunque altra cosa visualizzi una pagina web.

Per oscuri motivi però, il modulo ICU è linkato a QtCore e dunque ne diviene automaticamente dipendenza anche se si esclude a priori l’utilizzo del modulo WebKit.

Dato che per ovvi motivi la situazione ha scatenato abbastanza polemiche è probabile che più avanti il team di sviluppo del framework decida di optare per un’alternativa ad ICU.

Al momento, l’unica manovra attualmente applicabile sarebbe quella di compilare autonomamente tutto il framework Qt sulla propria macchina escludendo, attraverso opportuni parametri, l’utilizzo del modulo ICU.

L’esclusione di ICU, per quanto detto poco prima, porterebbe ovviamente alla mancanza del modulo QtWebKit ma se la nostra applicazione non deve farne utilizzo ciò si tradurrebbe nella fantastica prospettiva di poter distribuire applicazioni che non necessitino di megabytes di inutili dipendenze.

Al momento non ho idea se ciò sia facilmente e realisticamente fattibile. Basti pensare che per compilare l’intero framework ci vogliono ore.

Ad ogni modo scopriremo presto quale sarà l’evoluzione dei fatti.