[Gfoss] Compilazione qgis su windows

Dom 8 Ago 2010 17:08:36 CEST

Carissimo Sandro,
ben vengano queste tue email,sono sempre un'occasione di confronto e
di riflessione.
Sarebbe bello potersi confrontare, in un contesto magari tipo gfoss
day, su questo argomento. Ne parliamo spesso in lista, ma le email
sono sempre troppo esposte a flame e fraintendimenti... Che ne dite se
organizzassimo una piccola tavola rotonda con dialogo aperto, la
prossima volta che ne avremo l'occasione?

Dico la mia solo per punti, sinteticamente:

1 - molte aziende di sviluppo e molti clienti richiedono di sviluppare
su/per ambiente Windows. Ognuno è libero di pensare quel che vuole,
tanto più se cerca di aderire alla logica del solftware libero, ma non
sempre le scelte personali sono totalmente libere dal contesto
professionale in cui uno opera. Mi piace Linux, la storia e le
comunità che ci stanno dietro. Sostengo, anche nei confronti coi
colleghi e i clienti, la bontà dello sviluppo e dell'approccio FOSS,
anche perché mi ha permesso di imparare tante cose, di crescere nelle
mie competenze sui GIS e sull'informatica in genale. Ma questo non è
sufficiente per tanti (e per me) per svincolarsi da Windows. Sia per i
motivi suddetti, sia perché è un ambiente che, in fin dei conti, non
mi dispiace poi così tanto. Mi chiederai cosa ci faccio qua, mi dirai
che sono incoerente... Forse. Io spingo il più possibile verso FOSS,
anche nei corsi che tengo, ma il mondo è bello perché vario :)

2 -
> non a caso, la GPLv3 *impone* l'uso degli strumenti
> standard GNU per il build-system: il mancato rispetto
> di questa clausola è di per se stesso una violazione
> della licenza.

Quindi tutto ciò che viene distribuito su Osgeo4w, riguardo qgis,
viola la licenza? Lo chiedo seriamente, perché non mi sembra
un'affermazione da poco.
In passato ho chiesto molto sui due build system, i confronti in lista
sono stati molto serrati in certi periodi. Ho tirato su qgis e grass
sia tramite MinGW che tramite MSVC, con risultati più o meno buoni,
partendo dal problema che è tosto mettere insieme Qgis e Grass tramite
MSVC. Perché tutto ciò, se con MinGW è tutto (più o meno) più lineare,
o almeno più compatibile col build su Linux? Anzitutto perché in
molti, su Windows, sviluppano più probabilmente su VS. Secondo perché,
come emerso in precedenti discussioni, il codice prodotto da MSVC è
più performante su Windows. A questo proposito, se non siete
d'accordo, cerco i vecchi riferimenti, perché io non sono in grado di
snocciolarvi benchmark e motivi tecnici specifici... Diciamo che mi
fido di chi ne sa più di me su questo argomento (tra cui, senz'altro,
Jurgen Fischer!).
Aggiungo brevemente. Non tutti siamo espertissimi di ambienti di
build, tantomeno di debug. Debuggure su MSVC è a dir poco banale...
tramite MinGW dovrei usare GDB, che trovo molto meno banale. Ok, uno
può sempre imparare... ma questi spesso non possono che rimanere buoni
propositi!

3 - Sono d'accordo che sia importante mantenere alta la coscienza di
chi lavora con strumenti OS, ma credo vada accolto anche chi non
riesce/può a essere un "purista" al 100%. Ripeto quello che ho detto
tante altre volte: non tutte le svariate esigenze professionali hanno
pari soluzioni proprietarie e non, per Windows e per Linux. A volte ci
sono solo le une o le altre. E talvolta il contesto richiede l'uso di
un prodotto indipendentemente dalla sua GPLness... In generale siamo
sempre tutti d'accordo, ma cerchiamo di non essere troppo generalisti.
Ogni situazione ha un perché, e a parte i casi eclatanti di
"parassitismo" e pigrizia, siamo comprensivi. Da questo direi, ben
vengano anche gli sforzi di mantenere un build systems non purissimo
per Qgis e tutto il resto dell'armamentario...
(domanda da poll per chi sviluppa su Windows: "quale build-system
usate?". Io un'idea sulle percentuali già ce l'ho)

So di essere sempre borderline con le mie idee, ma spero siano un
contributo al confronto. Che spero, prima o poi, potremo sviluppare
dal vivo!

Giovanni

Il 08 agosto 2010 12:47,  <a.furieri a lqt.it> ha scritto:
> Scusatemi se abuso della paciosa tranquillità di una
> domenica mattina di agosto, ma dato che "ho un sassolino
> nella scarpa", ne approfitto per togliermelo.
>
> le regole elementari della GNU foundation sono assai
> chiare (e ben solidamente motivate): perchè un SW
> possa dirsi libero (ma libero veramente) non basta
> semplicemente rilasciare i sorgenti.
> e non basta neppure adottare una qualche licenza o.s.
>
> occorre anche utilizzare un build-system conforme,
> in modo tale che tutto risulti facilmente interoperabile,
> senza costringere sviluppatori e system maintainer
> a dover fare le capriole per aggirare le cento buche
> ed i mille ostacoli che impediscono di fare una build
> effettivamente funzionante.
>
> esiste un compilatore standard (anzi, una ricca di suite
> di compilatori): GCC
> ed esiste una serie di strumenti standard per la
> configurazione: AUTOTOOL (libtool, autoconf, automake)
>
> funzionano, sono efficienti, sono disponibili su
> tutte le piattoforme "ragionevoli", garantiscono
> efficacemente tutto quello che serve per una facile
> migrazione cross-platform.
>
> p.es. su WinOz esiste MinGW/MSYS, che permette di
> sviluppare agevolmente usando strumenti assolutamente
> conformi.
>
> esistono anche altre alternative (CMake etc): sicuramente
> possono anche essere "appetibili" in alcuni casi.
> resta il fatto che possono causano problemi (anche grossi)
> di interoperabilità con gli autotools.
>
> quindi perchè vengono utilizzati ?
> risposta facile facile: perchè rendono molto più facile
> l'integrazione con gli strumenti M$ tipo VisualStudio.
>
> ok, nulla in contrario. più opzioni abbiamo, meglio è.
> a patto però non rendano più incasinata l'integrazione
> con gli autotools e con gcc.

>
> infine, abbiamo i mille problemi che nascono da MSVC,
> cioè dal compilatore C/C++ di M$
>
> ripeto: non ho nulla in contrario, chi vuole e lo
> trova comodo usi tranquillamente MSVC.
> nessuna scomunica, nessun interdetto: consesso che
> a volte anch'io lo uso, se non altro per verificare
> la compatibilità del codice che sviluppo.
> resta il fatto che MSVC *non* è affatto uno strumento
> free-sw (anche se è disponibile gratuitamente).
>
> non solo: MSVC presenta un sacco ed una sporta di
> 'idiosincrasie' assolutamente fuori standard.
> sviluppare C/C++ su MSVC è una ricetta sicura al 100%
> per ottenere codice assolutamente non-portabile.
> viceversa, adattare codice sviluppato su GCC in modo
> tale che possa essere compilato con successo anche da
> MSVC è cosa abbastanza agevole.
>
> allora, se tutto questo è vero (è vero, è vero ...),
> perchè mai organizzazioni che tanto sbandierano al vento
> la propria appartenenza al movimento per il sw libero
> poi usano e supportano proprio MSVC ?????????????
>
> io la trovo personalmente una grossa, enorme contraddizione.
> e non si tratta affatto di un semplice puntiglio formale:
> la cosa implica svariate conseguenze di ordine pratico.
>
> molti packages che si compilano in modo assolutamente liscio
> su Linux danno invece mille problemi con MinGW/MSYS.
> perchè succede questo ?
> semplice, perchè gli sviluppatori hanno letteralmente
> farcito il codice con macro condizionali assolutamente
> specifiche per MSVC che risultano quindi incompatibili
> con gli strumenti standard.
>
> paradossale, vero ? però è esattamente così.
> vogliamo guardare "in casa nostra" ?
> - geos
> - proj4
> - geotiff
> sicuramente sono librerie assolutamente strategiche.
> altrettanto certamente per riuscire a fare una
> build su MinGW/MSYS occorre armarsi di santa
> pazienza e procedere al sapiente "scaccolamento"
> manuale del codice, dei makefiles etc etc.
>
> e non mi si venga a dire che "la colpa è di WinOz,
> che ha le sue stranezze".
> packages *mostruosi* come p.es. wxWidgets (100 MB
> di sorgenti) compilano in modo assolutamente
> liscio e senza nessun problema di sorta anche in
> ambiente MinGW/MSYS
> ergo, non è un problema 'tecnico': direi che
> piuttosto è un problema di volonta è di priorità
> nelle scelte strategiche.
>
> et in cauda venenum: io personalmente non ho mai
> avuto il piacere di riuscire a fare una build
> *completa* di QGIS su WinOz ... neppure usando
> MSVC: mi sono sempre dovuto accontentare di una
> build "castrata" (p.es. senza supporto python),
> e comunque ho sempre dovuto sudare non poco per
> "aggiustare a martellate" qualche intoppo qua e la.
> non dubito affatto che il sistema automatico delle
> nightly-build adottato da OsGeo4W funzioni perfettamente;
> ma evidentemente c'è qualche "pezzetto magico" che
> non è mai stato rilasciato ne tantomeno pubblicamente
> documentato.
>
> scusatemi se vi ho tediato con queste mie considerazioni,
> ma credo proprio che ... c'è del marcio in Danimarca :-)
>
> ciao Sandro
> _______________________________________________
> Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione
> Gfoss a faunalia.it
> http://lists.faunalia.it/cgi-bin/mailman/listinfo/gfoss
> Questa e' una lista di discussione pubblica aperta a tutti.
> I messaggi di questa lista non rispecchiano necessariamente
> le posizioni dell'Associazione GFOSS.it.
> 460 iscritti al 15.7.2010
>