Qt creator deployment
Axel
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.
michelangelo giacomelli
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.....
Axel
> Axel ha scritto:
>> [...]
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!
michelangelo giacomelli
> 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!
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
Gianni Valdambrini
> 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.
>
> 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.
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 ;)
Axel
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.
Axel
>> 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 tutorialhttp://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.
>
> Le Qt per windows vengono distribuite attualmente in 3 edizioni:
> - l'sdk
> - i sorgenti per mingw
> - i sorgenti per visual studio.
>
> 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
> 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.
>
> 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 ;)
Grazie anche a te per la risposta, effettivamente in modalit� release le
dll sono molto pi� leggere, non leggerissime, ma va molto meglio.
michelangelo giacomelli
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...
Axel
> Axel ha scritto:
>> stare, storco un po' il naso al pensiero di un programmino semplice da
>> inviare via e-mail.
> 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...
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.
michelangelo giacomelli
si decompila in ram e poi si esegue, comprime molto ed ￜ molto veloce.
http://upx.sourceforge.net/
puￜ comprimere pure dll.
michelangelo giacomelli
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
Guglielmo Calligaro
> ogni sistema operativo e libreria.
>
> 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".
michelangelo giacomelli
>> Il discorso ￜ fatto pensando a windows e qt ma a grandi linee vale per
>> ogni sistema operativo e libreria.
>>
>> 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.
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.
Guglielmo Calligaro
> si decompila in ram e poi si esegue, comprime molto ed ￜ molto veloce.
> http://upx.sourceforge.net/
> 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?
michelangelo giacomelli
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.
Guglielmo Calligaro
> 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.
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.