Newsgroup: it.comp.lang.c++
Titolo: Qt creator deployment

Chiedo scusa se l'argomento ï¿œ giï¿œ stato trattato, sto sperimetnando le 
librerie Qt, devo dire che mi trovo abbastnza bene, l'SDK ï¿œ certametne 
molto ben fatto, tuttavia non riesco ad ottenere un eseguibile 
funzionante, ho trovato degli articoli, ma nessuno sembra funzionare.
Sto sviluppando sotto windows, con l'installazione standard del Qt 
creator il linking dovrebbe essere dinamico, ma non vengono generate in 
automatico le dll per soddisfare le dipendenze.
seguendo questo tutorial
http://doc.trolltech.com/4.4/deployment-windows.html
non riesco nemmeno ad eseguire i comandi da riga di comando, 
probabilmente dovrei aggiungerli nelle variabili utente, ma nmake non lo 
trovo nemmeno, mentre qmake anche lanciandolo dal suo percorso non va.
Possibile non ci sia un modo per ottenere un eseguibile funzionante con 
tutte le dipendenze direttamente dal Qt creator?
Grazie.

Axel ha scritto:

Premetto che non sono pratico di windows...
Ma non ï¿œ che tutte le volte che fai un build del progetto debbano venire
"generate" le dll (a meno che non siano custom del progetto) secondo me
semplicemente ti manca nella variabile di ambiente path la directory che
contiene le dll di qt4.
Qualcosa tipo tipo C:\qt4\bin o similari...
Inoltre se hai installato il qtcreator probabilmente hai preso il
pacchetto che contiene il mingw (quindi hai il gcc e make, l'nmake non
ti serve fa parte del pacchetto visual-c++)
comunque guarda anche senza usare il qtcreator ma anche un editor di
testo come vi,emacs o anche notepad++ col qmake puoi semplicemente fare:
(premesso che c:\qt4\bin o simile deve essere nel path)
(premesso che probabilmente anche la variabile di ambiente qtdir
dovrebbe puntare a c:\qt4 o similari)
(premesso che anche la directory del mingw deve stare nel path qualcosa
tipo c:\mignw)
cd c:\mioprogetto\
c:\mioprogetto\qmake -project (analizza e crea il file .pro)
c:\mioprogetto\qmake -o Makefile 
mioprogetto.pro
 (crea il makefile)
make (<- invochi quello del mingw)
(apposto hai l'eseguibile)
Per il deploy analizzi il file .pro vedi che moduli usa e distribuisci
il tuo eseguibile e le .dll (prese da c:\qt4) se sono nella stessa
directory non hai problemi di settare path o simili, in alternativa devi
fare un installer che piazzi qtcore.dll, qt.dll... etc... sotto c:\windows.
Spero di esserti stato d'aiuto ï¿œ assai tanto tempo che non utilizzo
windows.....

> [...]

Grazie mille! Si copiando le dll nella cartella dell'eseguibile 
l'applicazione parte senza problemi.
unica nota negativa ï¿œ che QtGuid4.dll, da inserire praticamente sempre, 
occupa 135 MB, ma con le risorse degli attuali sistemi di calcolo non ï¿œ 
un vero ostacolo...
Grazie ancora!

 Grazie ancora!
mi verrebbe da dire e grazie al cazzo... ï¿œ la versione di debug con
ducentomila simboli...
Senti su windows non so davvero aiutarti, ma dovresti cercare o
compilare una versione delle qt senza il supporto al debug, giusto per
la distribuzione altrimenti ti spari.
micheg

 Grazie.
Le Qt per windows vengono distribuite attualmente in 3 edizioni:
 - l'sdk
 - i sorgenti per mingw
 - i sorgenti per visual studio.
Se non ricordo male l'sdk è corrispondente alla versione per mingw +
qtcreator. Inoltre mentre con la versione mingw puoi far il download
di questo compilatore e trovartelo automaticamente configurato per
compilare le Qt, con la versione per visual studio devi avere a tua
disposizione una delle versioni del compilatore Microsoft, ed è per
questo che non trovi nmake.
Per quanto riguarda il problema con qmake, probabilmente non stai
usando la console di msdos che viene fornita (mi sembra, vado a
memoria e potrei fare quindi confusione con una delle altre versioni
di Qt) e che automaticamnete imposta i path giusti per farti trovare
il compilatore.
Questo è indipendente da se compilare staticamente o dinamicamente:
mentre nel primo caso avrai tutto dentro al tuo eseguibile nel secondo
avrai ovviamente bisogno delle dll di Qt che stai usando, ma di certo
non si tratta di 130 MB ;)

michelangelo giacomelli ha scritto:

Ho compilato come release ed in questo modo mi richiede le dll normali, 
effettivamnte la situazione migliora molto, ma QtGui4.dll occupa 
comunque 11MB.
Beh molto meglio insomma su una applicazione piuttosto complessa ci puï¿œ 
stare, storco un po' il naso al pensiero di un programmino semplice da 
inviare via e-mail.

 non si tratta di 130 MB ;)
Grazie anche a te per la risposta, effettivamente in modalit� release le 
dll sono molto pi� leggere, non leggerissime, ma va molto meglio.

Axel ha scritto:

Il programmino "calcolatrice" probabilmente non ï¿œ il target delle
librerie, se devi fare qualcosa che sta in 300kb da spedire via mail
meglio qualcosa di piccolo e compilabile staticamente, uso tipico delle
librerie fltk.
fltk.org
ciao...
oppure puoi provare il caro e vecchio upx se esiste ancora...

 oppure puoi provare il caro e vecchio upx se esiste ancora...
Per il tipo di applicazione che dovrei sviluppare ora credo che le Qt 
vadano bene, ero solo un po' sorpreso :-)
mi intrigano sopratutto i database integrati!
di fltk avevo sentito parlare, dopo visito il sito.
anche le wxwidjets mi erano piaciute, upx invece non lo conosco.
Grazie davvero di tutto.

Axel ha scritto:

upx ï¿œ un compressore di eseguibili, ti crea una versione che a runtime
si decompila in ram e poi si esegue, comprime molto ed ï¿œ molto veloce.
http://upx.sourceforge.net/
puï¿œ comprimere pure dll.

Parto dai presupposti di questa discussione per aggiungere due parole
sulle dll di qt ma cercando di fare un discorso generale.
Se si compila per ottenere un eseguibile linkato a librerie dinamiche
c'ï¿œ il vantaggio di avere un eseguibile molto piccolo che si appoggia a
dll anche molto grandi, ci sono tools come upx che possono ridurre le
dimensioni delle dll, ma in generale il vantaggio dovrebbe essere che
appoggiandosi a librerie "note" queste dovrebbero essere giï¿œ presenti
sui pc su cui viene distribuita l'applicazione oppure si presume che i
gestori di queste macchine siano in grado di installare il runtime da soli.
Se ï¿œ comune trovare il runtime di qt su macchine linux questo non ï¿œ
certo vero per windows, inoltre c'ï¿œ da considerare che eseguibili
compilati col mingw avranno bisogno del supporto a runtime del mingw.
In generale un applicazione come Dependency Walker
(
http://www.dependencywalker.com/
) permette di ottenere una lista di dll
necessarie per il corretto funzionamento dell'applicazione.
Ad esempio un'applicazione qt compilata in versione release (ossia senza
simboli di debug) avrï¿œ bisogno di qt4core.dll, qt4gui.dll (e mingw.dll
se compilata col port di gcc) a fronte di un eseguibile magari di 50k ci
saranno quasi 15mega di dll; upx puï¿œ ridurre qt4gui.dll a 4,5 mb e le
altre a poche centina di k, praticamente uno zip contenente eseguibile e
dll sarï¿œ sui 6 mega che non credo di questi tempi sia un grande
problema. Ovviamente una soluzione piï¿œ elegante sarï¿œ un installer che se
mancano nei path di sistema le librerie di runtime di qt, penserï¿œ ad
installarle in modo che la volta successiva sia necessario scaricare il
mero eseguibile dell'applicazione.
Il discorso ï¿œ fatto pensando a windows e qt ma a grandi linee vale per
ogni sistema operativo e libreria.
Correzioni? Integrazioni?
micheg

 Correzioni? Integrazioni?
La mia esperienza in applicativi desktop sopratutto in ambiente Windows 
mi ha portato ad evitare il piu' possibile DLL gia' presenti nel 
sistema. Il motivo e' molto semplice e riguarda il versioning.
Se un altro programma fatto male mi fa un downgrade della DLL, me la 
cancello o anche piu' semplicemente me la aggiorna ma ad una versione 
che purtroppo non e' piu' compatibile con il mio applicativo sono 
cazzi.
Le mie scelte sono normalmente due :
1) Se faccio un programmino non impegnativo cerco di avere tutto 
linkato staticamente (ovviamente il minimo indispensabile). Ci guadagna 
il deployment (nella migliore delle ipotesi basta copiare un file .exe) 
e non ho tutti i problemi legati alla gestione di n file sparsi in 
giro. Se le librerie che uso sono fatte bene non avro' eseguibili 
enormi.
2) Se faccio un progetto complesso uso molte DLL piu' piccole possibili 
(bhe' senza esagerare ovviamente), tutte rigorosamente nella stessa 
cartella degli eseguibili. Se devo rilasciare degli aggiornamenti posso 
ridurli all'osso perche' andro' a toccare solo quello che 
effettivamente e' cambiato (evviva chi ha inventato l'autoupdate da 
internet).
Secondo il mio modesto parere la concorrenza nel mercato del software 
si fa anche curando la semplicita' di messa in funzione e la 
manutenzione piu' che la dimensione.
Posso scaricarmi un programmino da 15k pero' se non parte perche' mi 
serve il framework da 100mb oppure comincia a dirmi che la versione non 
e' aggiornata bla bla bla che non so cos'e' e cosa mi succede dopo  
posso anche trovare l'utente che non ne ha nessuna voglia e lascia 
subito perdere.
Ho notato che l'utente tollera bene anche un installazione "pesante" se 
tutto funziona subito. Messo poi incondizioni di poter lanciare quando 
vuole un aggiornamento automatico da internet che gli scarica in pochi 
secondo una manciata di k (giusto l'indispensabile) lo vedi proprio 
godere quando gli compare il messaggio "Aggiornamento effettuato con 
successo".

 che purtroppo non e' piu' compatibile con il mio applicativo sono cazzi.
azz... sono migrato via da windows a fine 1998 ma vedo che il dll hell
colpisce ancora a quasi 12 anni di distanza...
e che l'utunto continua ancora a premere su si quando il setup dice:
"nel sistema ï¿œ presente una versione piï¿œ recente sovrascrivo?"
(e l'utente subito su certo, avanti, avanti, non va un cazzz...)
:)
:)
ovviamente era ironico le tue indicazioni sono valide.

 puï¿œ comprimere pure dll.
Non lo conoscevo, l'ho provato e funziona davvero bene (sia con .exe 
che con .dll) ma superato l'entusiasmo iniziale una domanda mi sorge 
spontanea, a che pro? Visto e considerato che e' buona norma e regola 
(addirittura in alcuni casi inevitabile) veicolare eseguibile / 
installazioni sulla rete rigorosamente zippati non e' una perdita di 
tempo?

Guglielmo Calligaro ha scritto:

in questo caso ti serve ad una mazza, mentre ad esempio con fltk o
wxwidgets che meglio si prestano alla compilazione statica di
eseguibile, visto che alla fine distribuisci un unico .exe e spesso
l'utonto quando vede uno zip si spaventa, puï¿œ essere utile.

 l'utonto quando vede uno zip si spaventa, puï¿œ essere utile.
Mi preoccupava il .exe su internet ma stavo pensando che puoi spedire 
il solito .x da rinominare in .exe (per evitare il blocco 
antivirus/antispam/smtpstronzo/etc) evitando la decompressione che fa 
partire l'embolo all'utonto :-P come giustamente dicevi.
Ma anche una banalissima .dll di aggiornamento per l'utente skilled 
(anche li eviteresti un passaggio).
Si, pensandoci bene e' da prendere seriamente in considerazione.