Compilazione qgis su windows

[Andrea Peri]

Salve,

tempo fa' mi sono cimentato con il tentativo di compilare qgi con
visualC, ma alla fine rinunciai.
Non riuscivo a rimettere insieme tutti i pezzetti necessari (tenendo
presente che volevo ricompilare dai sorgenti qualunque pezzetto di dll o
codice coinvolto)

Ora, che ho un po' di tempo vacanziero, ci riproverei con nuova lena.
Ma vorrei optare per altro ambiente.

Sul manuale di qgis e' descritta per sommi capi una compilazione usando
"msys".

http://www.qgis.org/wiki/Installation_Guide#Building_under_windows_using_msys

E da li vengo ricondotto a un tutorial di Pasetti (che sembra fatto
molto bene ... poi faccio sapere come e' andata...)

Prima di iniziare pero' avrei bisogno di un chiarimento.

Devo usare le versioni indicate nel tutorial o posso estendermi a
impiegare le ultime release di versione disponibili per ognuna delle
tante librerie coinvolte ?

Infatti non vorrei arrivare alla fine, dopo aver fatto tutto il percorso
e scoprire che non compila ta 1.6.x .

Grazie.

Andrea Peri.

_______________________________________________
Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione
[hidden email]
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

[a.furieri]

On Sat, 07 Aug 2010 08:29:53 +0200, Andrea Peri 2007 wrote

> Salve,
>
> tempo fa' mi sono cimentato con il tentativo di compilare qgi con
> visualC, ma alla fine rinunciai.
> Non riuscivo a rimettere insieme tutti i pezzetti necessari (tenendo
> presente che volevo ricompilare dai sorgenti qualunque pezzetto di
> dll o codice coinvolto)
>
> Ora, che ho un po' di tempo vacanziero, ci riproverei con nuova lena.
> Ma vorrei optare per altro ambiente.
>
> Sul manuale di qgis e' descritta per sommi capi una compilazione
> usando "msys".
>
> http://www.qgis.org/wiki/Installation_Guide#Building_under_windows_using_msys
>
> E da li vengo ricondotto a un tutorial di Pasetti (che sembra fatto
> molto bene ... poi faccio sapere come e' andata...)
>

Andrea, attenzione.
il tutorial del Pasetti ormai è sicuramente datato ed obsoleto.
già svariati mesi fa circa metà delle indicazioni fornite non
risultavano più attinenti/applicabili perchè erano cambiate
le versioni delle librerie.

in ogno caso quel tutorial era basato su MSYS/MinGW: se tu
invece intendi usare VisualC "non c'azzecca nulla", perchè si
tratta di un ambiente di sviluppo completamente diverso.

Giusto in pillole:
MSVC è il compilatore M$ per Windows, con tutte le ennemila
stranezze windowsiane microsoftare del caso.
MSYS+MinGW è 'quasi' come lavorare su una shell Unix con gcc,
anche se in effetti gira su Win: ma al 90% è unix-like.


> Prima di iniziare pero' avrei bisogno di un chiarimento.
>
> Devo usare le versioni indicate nel tutorial o posso estendermi a
> impiegare le ultime release di versione disponibili per ognuna delle
> tante librerie coinvolte ?
>
> Infatti non vorrei arrivare alla fine, dopo aver fatto tutto il
> percorso e scoprire che non compila ta 1.6.x .
>

Le ultime versioni binarie per WinOz di QGIS sono compilate con
MSVC: quindi sicuramente riesci a compilare tutto sotto MSVC.
e non hai nessun bisogno di confonderti con le librerie, visto
che basta semplicemente che tu installi quelle precompilate
da Osgeo4W: http://trac.osgeo.org/osgeo4w/

btw, le Oegeo4W sono esattamente quelle utilizzate per le
release ufficiali di QGIS WinOz; quindi (oltre a risparmiarti
una bella faticata) sei anche sicuro della compatibilità.

riassumendo:
a) prima ti installi le librerie da Osgeo4W
b) poi scarichi i src QGIS
c) fai girare CMake selezionando MSVC come compilatore
d) lanci la build dall'IDE di Visual Studio
e) a questo punto tieni le dita incrociate, stringi
   forte un corno di corallo rosso e reciti il rosario
   e le litanie ... mentre aspetti pazientemente
f) sicuramente incontrerai qualche intoppo, ma usando
   fantasia e creatività è molto facile che tu riesca
   ad uscirne fuori ancora vivo :-)

ciao Sandro
_______________________________________________
Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione
[hidden email]
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

[pcav]

On Sat, 07 Aug 2010 08:29:53 +0200, Andrea Peri 2007 <[hidden email]>
wrote:
> tempo fa' mi sono cimentato con il tentativo di compilare qgi con
> visualC, ma alla fine rinunciai.

> Infatti non vorrei arrivare alla fine, dopo aver fatto tutto il percorso
> e scoprire che non compila ta 1.6.x .

<caution>Io di windows non so nulla</caution>
Attenzione: la guida e' vecchia, sono cambiate un sacco di cose, e
attualmente MSVC credo sia l'unico ambiente di compilazione supportato
(purtroppo); ergo, ti avventuri in terreni incogniti, possibilissimo che
saltino fuori problemi.
In bocca al lupo, e tienici aggiornati sugli sviluppi!
--
http://faunalia.it/pc
_______________________________________________
Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione
[hidden email]
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

[Andrea Peri]

Grazie per i suggerimenti.

Se riesco a ricavare qualcosa di commestibile faccio sapere.

> Andrea, attenzione.
> il tutorial del Pasetti ormai è sicuramente datato ed obsoleto.
> già svariati mesi fa circa metà delle indicazioni fornite non
> risultavano più attinenti/applicabili perchè erano cambiate
> le versioni delle librerie.
>
> in ogno caso quel tutorial era basato su MSYS/MinGW: se tu
> invece intendi usare VisualC "non c'azzecca nulla", perchè si
> tratta di un ambiente di sviluppo completamente diverso.
>
> Giusto in pillole:
> MSVC è il compilatore M$ per Windows, con tutte le ennemila
> stranezze windowsiane microsoftare del caso.
> MSYS+MinGW è 'quasi' come lavorare su una shell Unix con gcc,
> anche se in effetti gira su Win: ma al 90% è unix-like.
>
>
>  
> Le ultime versioni binarie per WinOz di QGIS sono compilate con
> MSVC: quindi sicuramente riesci a compilare tutto sotto MSVC.
> e non hai nessun bisogno di confonderti con le librerie, visto
> che basta semplicemente che tu installi quelle precompilate
> da Osgeo4W: http://trac.osgeo.org/osgeo4w/
>
> btw, le Oegeo4W sono esattamente quelle utilizzate per le
> release ufficiali di QGIS WinOz; quindi (oltre a risparmiarti
> una bella faticata) sei anche sicuro della compatibilità.
>
> riassumendo:
> a) prima ti installi le librerie da Osgeo4W
> b) poi scarichi i src QGIS
> c) fai girare CMake selezionando MSVC come compilatore
> d) lanci la build dall'IDE di Visual Studio
> e) a questo punto tieni le dita incrociate, stringi
>    forte un corno di corallo rosso e reciti il rosario
>    e le litanie ... mentre aspetti pazientemente
> f) sicuramente incontrerai qualche intoppo, ma usando
>    fantasia e creatività è molto facile che tu riesca
>    ad uscirne fuori ancora vivo :-)
>
> ciao Sandro
>
>  

_______________________________________________
Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione
[hidden email]
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

[giohappy]

Io ho seguito entrambe le strade, tempo fa.
Adesso però mantengo solo l'ambiente con MSVC (vs 2008) usando le
librerie precompilate di osgeo4w.
Con Cmake è piuttosto semplice generare la soluzione visual studio...

Anche a me piacerebbe però trovare il tempo di realizzare il tutto da
zero, e per questo ogni tanto cerco di strappare qualche informazione
a Jurger, che mantiene tutte le dll di osgeo4w. Spero che con lo
sforzo dei diversi interessati si riesca a mettere su una guida stile
Pasotti ma per MSVC.

giovanni

Il 07 agosto 2010 14:37, Andrea Peri 2007 <[hidden email]> ha scritto:

> Grazie per i suggerimenti.
>
> Se riesco a ricavare qualcosa di commestibile faccio sapere.
>
>
>> Andrea, attenzione.
>> il tutorial del Pasetti ormai è sicuramente datato ed obsoleto.
>> già svariati mesi fa circa metà delle indicazioni fornite non
>> risultavano più attinenti/applicabili perchè erano cambiate
>> le versioni delle librerie.
>>
>> in ogno caso quel tutorial era basato su MSYS/MinGW: se tu
>> invece intendi usare VisualC "non c'azzecca nulla", perchè si
>> tratta di un ambiente di sviluppo completamente diverso.
>>
>> Giusto in pillole: MSVC è il compilatore M$ per Windows, con tutte le
>> ennemila stranezze windowsiane microsoftare del caso.
>> MSYS+MinGW è 'quasi' come lavorare su una shell Unix con gcc,
>> anche se in effetti gira su Win: ma al 90% è unix-like.
>>
>>
>>  Le ultime versioni binarie per WinOz di QGIS sono compilate con MSVC:
>> quindi sicuramente riesci a compilare tutto sotto MSVC.
>> e non hai nessun bisogno di confonderti con le librerie, visto
>> che basta semplicemente che tu installi quelle precompilate
>> da Osgeo4W: http://trac.osgeo.org/osgeo4w/
>>
>> btw, le Oegeo4W sono esattamente quelle utilizzate per le
>> release ufficiali di QGIS WinOz; quindi (oltre a risparmiarti
>> una bella faticata) sei anche sicuro della compatibilità.
>>
>> riassumendo:
>> a) prima ti installi le librerie da Osgeo4W
>> b) poi scarichi i src QGIS
>> c) fai girare CMake selezionando MSVC come compilatore
>> d) lanci la build dall'IDE di Visual Studio
>> e) a questo punto tieni le dita incrociate, stringi
>>   forte un corno di corallo rosso e reciti il rosario
>>   e le litanie ... mentre aspetti pazientemente
>> f) sicuramente incontrerai qualche intoppo, ma usando
>>   fantasia e creatività è molto facile che tu riesca
>>   ad uscirne fuori ancora vivo :-)
>>
>> ciao Sandro
>>
>>
>
> _______________________________________________
> Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione
> [hidden email]
> 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
>

_______________________________________________
Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione
[hidden email]
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

[a.furieri]

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.
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.

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
[hidden email]
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

[giohappy]

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,  <[hidden email]> 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
> [hidden email]
> 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
>

_______________________________________________
Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione
[hidden email]
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

[pcav]

Il 08/08/2010 12:47, [hidden email] ha scritto:

> 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 ?????????????

Aspetta: vuoi dire che osgeo4w e' incompatibile con programmi che abbiano la licanza
GPLv3?
Al momneto mi pare che siano tutti (ecetto i BSD/MIT ecc.) alla v2 *o superiore*, il
che potrebbe essere gia' ora un problema, comunque lo sara' nel futuro.
Sara' il caso che GFOSS.it faccia presente ufficialmente a osgeo il problema? Meglio
se attraverso il liason officer?
Grazie.
--
Paolo Cavallini: http://www.faunalia.it/pc
_______________________________________________
Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione
[hidden email]
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

[a.furieri]

On Wed, 11 Aug 2010 09:38:48 +0200, Paolo Cavallini wrote

> Il 08/08/2010 12:47, [hidden email] ha scritto:
>
> > 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 ?????????????
>
> Aspetta: vuoi dire che osgeo4w e' incompatibile con programmi che
> abbiano la licanza GPLv3? Al momneto mi pare che siano tutti (ecetto
> i BSD/MIT ecc.) alla v2 *o superiore*, il che potrebbe essere gia'
> ora un problema, comunque lo sara' nel futuro. Sara' il caso che
> GFOSS.it faccia presente ufficialmente a osgeo il problema? Meglio
> se attraverso il liason officer? Grazie.
>

NO.
mi sono andato a rileggere direttamente la GPLv3 (ed il
relativo forum giuridico): evidentemente mi ero lasciato
influenzare da rumors e chiacchiere che girano nei convegni.

Ad ogni buon conto la situazione "legale" per quanto ho
capito è esattamente questa:

a) la GPLv3 *impone* che quando si rilascia codice free,
   allora bisogna anche rilasciare i build scripts e gli
   scripts di installazione (ed anche questi scripts sono
   coperti dalla GPL, quindi possono essere modificati,
   redistribuiti etc etc)
b) ma non dice nulla circa l'esatta natura degli strumenti,
   compilatori etc che devono essere utilizzati.
   addirittura nel forum giuridico si parla esplicitamente
   dell'uso di compilatori proprietari, ed in questo caso
   consigliano di inserire avvertenze del tipo:
   "per compilare questo package è tassativamente richiesto
   il compilatore ABCD versione x.y.z ACME spa; purtroppo
   questo compilatore non è free, contattare il produttore etc"

l'unico dubbio legale che quindi resta in piedi per OsGeo4w
è quindi il seguente:
se è vero (come pare proprio essere vero) che nessun essere
umano "fuori dal giro" è mai riuscito a farsi autonomamente
una build completa su MSVC ... beh, qua c'è una sicura
violazione di licenza.

su questo la GPL è assai chiara: usando il codice, gli
scripts e la documentazione fornita chiunque deve essere
in grado di ricompilare gli eseguibili.
insomma, non è affatto ammesso "nascondere qualche piccolo
pezzettino sotto al tappeto"

ciao Sandro
_______________________________________________
Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione
[hidden email]
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

[a.furieri]

giusto un paio di informazioni tecniche su MinGW/MSYS
(cerco di rispondere cumulativamente sia ad Andrea
che a Giovanni):

a) si, è vero: installare MinGW/MSYS non è esattamente
   il top della semplicità. specie la prima volta può
   anche essere abbastanza sconvolgente.
   il punto è che si tratta di strumenti che seguono
   passo passo la logica operativa di Unix/Linux.
   certo, per chi è abituato a WinOZ può anche essere
   un bel trauma :-)

b) anche questo è vero: la versione stabile/ufficiale
   (quella con l'installer automatico, per capirsi)
   supporta un GCC "vecchiotto".
   però va anche detto che è assolutamente stabile,
   e che funziona perfettamente bene.
   io personalmente (in svariati anni di utilizzo)
   ho trovato una sola volta un package che dava
   qualche (modesto) problema di compilazione perchè
   usava qualche opzione introdotta con le ultimissime
   versioni di GCC.
   ed usando la versione "stabile" non esiste ovviamente
   nessun problema di solidità e replicabilità: l'ambiente
   è quello per tutti, non ci piove :-)
   e se compila con MinGW compila sicuramente anche con
   GCC su Linux e MacOsX ... scusate del poco.
   
c) viceversa, le versioni "sperimentali" di MinGW sono
   sicuramente più aggiornate ...
   peccato che (come dice il nome) non sono per nulla stabili,
   e forse neppure troppo affidabili.
   io personalmente non le uso affatto, e resto (codardamente)
   affezionato alla versione "stabile" (che comunque
   viene regolarmente aggiornata ogni paio di mesi).
   mai avuto neppure l'ombra di un problema.

d) MSVC genera codice che gira più veloce ...
   si, è sicuramente vero, confermo
   però va anche detto che un conto è fare qualche test
   "teorico", mentre tutt'altro conto sono i "casi reali".
   alla fine (intendo dire per applicazioni complesse)
   non esiste nessuna conseguenza pratica, o quasi.
   P.Es. tutte le versioni binarie di SpatiaLite per WinOz
   sono compilate esclusivamente con MinGW ... e non faccio
   altro che ricevere mail dagli utenti che si complimentano
   per la velocità di elaborazione :-)

e) piccola nota a margine: sarà anche vero che MSVC genera
   codice più efficiente ... ma il compilatore di per se
   è di una lentezza mortale.
   caso appena successo 5 minuti or sono: source bello
   pesantuccio, 50.000 righe di codice:
   mingw: qualche secondo
   msvc: circa 5 minuti !!!!!
   [n.b.: stesso PC in entrambi i casi]

f) sempre a proposito di velocità: in linea di massima
   va anche detto che Linux è sensibilmente più pimpante
   di WinOz praticamente in tutte le condizioni d'uso.
   - l'intero subsystem di I/O ha un'efficienza neppure
     lontanamente comparabile: specie per quanto riguarda
     la gestione del disk caching WinOz fa veramente pena
   - malloc / free su WinOz sono notoriamente di una
     lentezza/inefficienza esasperante
   - i vari gadgets gui, antivirus, servizi "oscuri"
     in background etc contribuisco un bel po' a
     mangiare quantità allucinanti di RAM, e rubano
     un bel po' di potenza di elaborazione.
   insomma, a parità di configurazione HW, Linux ha
   sicuramente "una marcia in più" rispetto a WinOz
   (a parte il fatto che è più stabile, più affidabile,
    più robusto, più sicuro etc etc etc etc etc etc)

ciao Sandro
_______________________________________________
Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione
[hidden email]
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