Polygen senza cygwin1.dll #13
Comments
|
Devi sapere che i ho provato dozzine di modi per usare mingw al posto di
cygwin, e perfino la nuova ubuntu per windows che funziona solo con la
falls update. È stato un bagno di sangue, molto peggiore di qualche anno
fa. Sono anni che uso sia cugwin che mingw, alternatamente, per certi
periodi, magari per progetti di lavoro ecc, ma da un paio d'anni mi ero
allontanato. Sono tornato e non funziona più un cazzo: conflitti tra i due,
versioni degli stessi comandi sovrascritte, path di ambiente devastato -
tutto così.
Ho risolto rinunciando sia a cygwin che a mingw: sto provando solamente WSL
(il linux nativo in w10 che dicevo prima) e ho una piacevole sensazione di
ordine - tutti i pacchetti debian si possono installare tranquilla in una
sandbox ubuntu, non mi sembra vero che l'abbia fatto Microsoft! 😂
Dopodiché ho osato cinentarmi nella configurazione di VSCode per OCaml,
cross-referendomi a WSL. Non l'avessi mai fatto! Non ne vengo fuori!!! Ci
sono guide frammentarie, poco frequentate e soprattutto già obsolete, come
sempre accade in queste cose desuete. Il mio obiettivo era avere un
ambiente di lavoro confortevole per il polygen, modernizzato ad un ide,
come ormai sono abituato a lavorare da anni, ma Windows è un portatore di
complicazioni assurde in questi casi.
È che onestamente mi secca programmare a editor e shell: sento che sono
lento e legnoso, ed ho paura a fare interventi grossi perché è tutto
scomodo. Insomma, provo ancora un po' e al massimo mi arrendo 😢
Per quanti riguarda msys: stanne alla larga. Anche quello è un mostro che
ti ci vogliono 2 giorni per sistemare. Io ti invito a provare WSL: lo so
che non tutti ce l'hanno e che non risolve il problema della distribuzione,
ma magari risolve temporaneamente, per noi, il problema dell'ambiente di
sviluppo.
Il giorno ven 19 gen 2018 alle 17:24 Tristano Ajmone <
notifications@github.com> ha scritto:
… Come compilare Polygen per Windows senza la dipendenza da cygwin1.dll.
Cygwin vs MinGW
Sul Wiki di MinGW <http://www.mingw.org/node/21> leggiamo (grassetto mio):
Cygwin in contrast to MinGW
Cygwin applications by principle are not considered a "Native Win32
application" because it *relies on the Cygwin® POSIX Emulation DLL or
cygwin1.dll for Posix functions* and does not use win32 functions
directly. *MinGW on the other hand, provides functions supplied by the
Win32 API*. While porting applications under MinGW, functions not native
to Win32 such as fork(), mmap() or ioctl() will need to be reimplemented
into Win32 equivalents for the application to function properly.
Lo stesso principio vale per MinGW-w64.
Questo thread su stackoverflow esamina i dettagli della questione:
https://stackoverflow.com/questions/187990/why-does-gcc-windows-depend-on-cygwin
In sintesi, se si compilasse Polygen usando MinGW-64 (GCC a 32 o 64 bit),
l'exe finale non dipenderebbe da alcuna DLL (le librerie di MinGW-64
possono essere linkate staticamente).
Il problema è che sul sito MinGW-w64 non sono disponibili versioni per
Windows che includano il supporto per OCaml. Però OCaml è disponibile in
MSYS2:
https://github.com/Alexpux/MINGW-packages
- mingw-w64-ocaml
- mingw-w64-ocaml-camlp4
- mingw-w64-ocaml-findlib
- mingw-w64-ocaml-lablgtk
MSYS2 vs Cygwin
Dal Wiki di MSYS2
<https://github.com/msys2/msys2/wiki/How-does-MSYS2-differ-from-Cygwin>
(grassetto mio):
How does MSYS2 differ from Cygwin
Cygwin and MSYS2 -- as projects -- have significantly different goals.
Cygwin tries to bring a POSIX-compatible environment to Windows so that
most software that runs on unices will build and run on Cygwin without any
significant modifications. Cygwin provides a large collection of packages
containing such software, and libraries for their development.
MSYS2 tries to provide an environment for building native Windows
software. MSYS2 provides a large collection of packages containing such
software, and libraries for their development. As a large portion of the
software uses GNU build tools which are tightly coupled to the unix world,
this environment is also POSIX-compatible, and is in fact based on Cygwin.
MSYS2 provies a minimal shell required to run autotools and other build
systems which get the source for software from the Internet from different
repositories, configure them and build them. *The shell and core tools
exist mainly to allow porting Unix programs to run natively on Windows
(i.e. without requiring a POSIX emulation layer)*. MSYS2 doesn't try to
duplicate Cygwin's efforts more than necessary, so the number of provided
POSIX-emulated software is very small.
Questo a conferma del fatto che MSYS2 consente la creazione di eseguibili
che non necessitano di DLL per emulare il layer POSIX.
MSYS2 + MinGW-w64
Da quello che ho capito leggendo la documentazione di MSYS2, per creare
eseguibili che non abbiano dipendenze da DLL, è necessario compilare con
MinGW-64.
Praticamente MSYS2 offre diversi ambienti di sviluppo, alcuni dei quali
legati al progetto MSYS2 stesso (e compilando in quell'ambiente si
producono eseguibili che necessitano di DLL per il layer POSIX, come
avviene con Cygwin), e infine vi sono gli ambienti MinGW-64 (a 32 o a 64
bit) che consentono invece di compilare eseguibili standalone che
implementano il layer POSIX tramite Win API (e dipendono dalle varie DLL di
MSVS, ormai presenti di default in tutte le versioni di Windows moderne).
Conclusioni
Io non ho avuto modo di testare quanto sopra. Sto valutando la possibilità
di installare MSYS2 e fare un tentativo (sto solo verificando che non vi
siano potenziali conflitti con altre applicazioni sulla mia macchina, ma
sembra che MSYS operi in un ambiente completamente isolato).
Tu hai modo di confermarmi se il sorgente di Polygen è compilabile con la
versione di OCaml che verrebbe installata da MSYS2? La v1.0.6 ha oltre 10,
magari OCaml è cambiato nel frattempo. Vorrei evitare di installare MSYS2
(che mi pare di capire richiederà mezza giornata, tra settaggi, librerie e
dipendenze, e cercare di capire come muovercisi dentro) solo per poi
scoprire che i sorgenti attuali (quelli del repo, o quelli della v1.0.6)
non possono compilare senza modifiche.
Che differenza c'è tra i sorgenti del repo (segnalati come v1.0.7) e
quelli invece disponibili dal sito (1.0.6 del 2005)?
Mi sarebbe piaciuto testarlo in altri modi, ma come ti dissi il mio
tentativo di installare OCaml (versione *OCPWin*, che contiene MinGW-w64)
su Windows è stato disastroso: l'antivirus mi ha ranzato via 60% dei binari
di OCaml. Le altre distribuzioni di OCaml per Win disponibili sono tutte
basate su Cygwin, allora tanto vale installare MSYS2 e poi scaricare OCaml
col suo package manager.
Purtroppo, anche i tentativi di cross compilare Polygen da Ubuntu tramite
MinGW-w64 sono falliti — credo per via del fatto che il makefile andrebbe
modificato per specificare di usare il crosscompilatore MinGW-w64 anziché
il compilatore OCaml.
Ad ogni modo, sarebbe utile a mio avviso considerare di appoaggiarsi a
MSYS2 per future compilazioni di Polygen per Windows, e liberarsi della
dipendenza da cygwin1.dll. Quando la versione di cygwin1.dll del sito
Polygen.org ha semsso di funzionare con Win 7, non sono più stato in grado
di usare Polygen per qualche anno; una seccatura.
Link di Approfondimento MinGW-w64
- https://mingw-w64.org
MSYS2
- http://www.msys2.org/
- MSYS2 WIki <https://github.com/msys2/msys2/wiki>
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#13>, or mute the thread
<https://github.com/notifications/unsubscribe-auth/ACcZxlNati24R9PAaTLwBFqhEnbyiHLOks5tMMFPgaJpZM4Rktse>
.
|
temevo problemi del genere, ed è per questo ero (e sono) riluttante a tentare e volevo un tuo feedback. Inoltre, trovo che la documentazione di MinGw-64 sia un po' caotica, ed è difficile farsi strada (a meno che non si è già utenti esperti di GCC), e anche solo capire cosa scaricare richiede ore di ricerche.
grazie per avermi messo in guardia. Stavo spilucchiando la documentazione, e anche se assicura che il tutto è in un ambiente isolato e virtuale, avevo la sensazione che fosse un po' macchinoso (daltronde non mancano le avvertenze circa i problemi a installare pacchetti)
Ottimo a sapersi. Avevo accolto il suo annuncio con un po' di scettismo, temevo avrebbe appesantito il sistema. E volevo evitare di ritrovarmi con un'ulteriore Bash e versione di Git — sembra che ogni pacchetto voglia installarne una, senza porsi il problema se ne hai già una sul sistema. Per forza di cosa, mi ritrovo già tre versioni di Git e un paio di Bash diverse. E che cavolo!
Lo prendo in seria considerazione. Mi documento meglio e cerco di pianificare la cosa. Resto dell'idea che cross-compilare da Linux sia più semplice. A volte mi ritrovo a dover compilare PP da Haskell, per Windows, ma lo faccio su Ubuntu direttamente che è molto più semplice. Se no, per il resto preferisco usare una virtual machine (come VMWare), almeno posso fare tutto dentro Windows (inclusi altri OS) ma senza sporcare il sistema di lavoro — almeno per fare le prove, tanto a distruggere un OS virtualizzato basta un click.
Bello VSCode, l'ho scaricato versione standalone e ci sto sperimentando. Prima di abbandonare Sublime Text vorrei aspettare un po' e vedere che piega prende, per ora mi sembra ancora un' applicazione un po' giovane, ma promette bene. Credo che potrebbe anche rubare il titolo a Sublime Text (anche solo per il fatto che è open source), anche se con grossi progetti tende ad essere meno performante (per via di Electron e Javascript).
Sì, ho avuto l'impressione che OCaml sia diventato un po' trascurato da questo punto di vista. Non ci sono IDE storiche dedicate ad OCaml? Io sto spulciando in rete, e per ora ho individuato queste (così, a muzzo, senza troppi approfondimenti per ora):
Le prime due IDE sembrano belle, e anche mantenute attivamente. La terza è vecchiotta, ma questo non vuol dire che non funzioni.
Io uso principalmente Sublime Text 3, che viene distribuito con supporto nativo per OCaml (non l'ho testato), ma esistono anche plugin aggiuntivi (pochi) per gestire meglio lo sviluppo in OCaml: Però ST è un prodotto commerciale, ma la licenza non è cara e alla fine l'ho acquistato. Comunque lo si può provare gratuitamente (senza limiti di funzionalità, e neanche di tempo, ti vien solo ricordato che devi comprare la licenza). Quindi (se già non l'hai fatto) puoi scaricare la versione standalone e provare come se la cava con OCaml. |
|
Ottimo a sapersi. Avevo accolto il suo annuncio con un po' di scettismo,
temevo avrebbe appesantito il sistema. E volevo evitare di ritrovarmi con
un'ulteriore Bash e versione di Git — sembra che ogni pacchetto voglia
installarne una, senza porsi il problema se ne hai già una sul sistema. Per
forza di cosa, mi ritrovo già tre versioni di Git e un paio di Bash
diverse. E che cavolo!
E' esattamente quello che ha mandato fuori di testa me: cominciavo ad avere
4 ocaml (uno windows nativo, uno cygwin, uno mingw e uno wsl), più 23000
shell, dozzine di comandi replicati in tutte le piattaforme -- e la cosa
che più mi faceva prurito alla schiena era che tutte queste schifezze
mettevano la loro cazzo di directory /bin nel PATH di sistema. Potevo
percepire lo stress della mia CPU che ogni 10 millisecondi doveva
scartabellare dozzine di cartelle alla ricerca di un cazzo di comando, e
così ho pulito tutto a mano e tenuto solo un ambiente minimale,
riproducibile, sperabilmente self-contained, cioè WSL.
Io ti invito a provare WSL: lo so che non tutti ce l'hanno e che non
risolve il problema della distribuzione, ma magari risolve temporaneamente,
per noi, il problema dell'ambiente di sviluppo.
Lo prendo in seria considerazione. Mi documento meglio e cerco di
pianificare la cosa.
Resto dell'idea che cross-compilare da Linux sia più semplice. A volte mi
ritrovo a dover compilare PP da Haskell, per Windows, ma lo faccio su
Ubuntu direttamente che è molto più semplice.
Non uso linux in questo periodo (anche se l'ho usato per molti anni ed,
anzi, ho perfino contribuito alla sua diffusione su Amiga facendo un
porting di XFree86 per i chipset AGA nel '98) ma ho sempre la tentazione di
installarmi VMware e fare tutto da lì: sarebbe anche più semplice VSCode e
tutte queste minchiate. Tra l'altro, Polygen l'ho scritto proprio su Linux
- non su Amiga purtroppo, perché nel 2002 l'avevo da poco abbandonata per
un volgare PC dell'epoca - quindi sarebbe un ritorno a casa per lui :) Ci
penserò. Io non ho nulla contro Linux, anzi lo trovo il miglior kernel tra
i 3 più diffusi ad oggi, però quello che detesto è avere 2 sistemi
operativi.
Se no, per il resto preferisco usare una virtual machine (come VMWare),
almeno posso fare tutto dentro Windows (inclusi altri OS) ma senza sporcare
il sistema di lavoro — almeno per fare le prove, tanto a distruggere un OS
virtualizzato basta un click.
Infatti è la mia prossima strada se quella di WSL non funziona.
Dopodiché ho osato cinentarmi nella configurazione di VSCode per OCaml,
cross-referendomi a WSL. Non l'avessi mai fatto! Non ne vengo fuori!!!
Bello VSCode, l'ho scaricato versione standalone e ci sto sperimentando.
Prima di abbandonare Sublime Text vorrei aspettare un po' e vedere che
piega prende, per ora mi sembra ancora un' applicazione un po' giovane, ma
promette bene. Credo che potrebbe anche rubare il titolo a Sublime Text
(anche solo per il fatto che è open source), anche se con grossi progetti
tende ad essere meno performante (per via di Electron e Javascript).
Sublime l'ho usato superficialmente perché da quando è famoso non ho mai
avuto occasione di lavorare ad un progetto in cui fosse necessario (ho
sempre usato altri IDE più integrati, come i vari IntelliJ o VS).
Com'è programmare in OCaml su Sublime? Ho letto che non è molto meglio di
Atom o VSCode, quindi a parità di condizioni ho preferito quello che
sembrava avere la plugin migliore (VSCode appunto), ma devo ancora riuscire
a farlo funzionare correttamente :(
Il mio obiettivo era avere un ambiente di lavoro confortevole per il
polygen, modernizzato ad un ide, come ormai sono abituato a lavorare da
anni, ma Windows è un portatore di complicazioni assurde in questi casi.
È che onestamente mi secca programmare a editor e shell: sento che sono
lento e legnoso, ed ho paura a fare interventi grossi perché è tutto
scomodo. Insomma, provo ancora un po' e al massimo mi arrendo
Sì, ho avuto l'impressione che OCaml sia diventato un po' trascurato da
questo punto di vista. Non ci sono IDE storiche dedicate ad OCaml?
Incredibilmente no. C'erano 13-15 anni fa degli esperimenti e sembrava
fossero al punto di farne, ma alla fin fine non è mai andato oltre la
"plugin buggata per Eclipse" o, al giorno d'oggi, la "plugin buggata per
VSCode".
E' incredibile come anni fa si faceva tutto con un editor di merda ed una
shell - ed eri felicissimo se avevi anche solo il syntax highlightening
(che ti configuravi rigorosamente a mano). Adesso non ci riesco più a
lavorare senza IDE! Mi vergogno di me :)
Io sto spulciando in rete, e per ora ho individuato queste (così, a muzzo,
senza troppi approfondimenti per ora):
- OCamlEditor <http://ocamleditor.forge.ocamlcore.org/>
- OCaml-Top <https://www.typerex.org/ocaml-top.html>
- Camelia <http://camelia.sourceforge.net> (del 2005!)
Camelia è esattamente il progetto che ricordava: mai stato bello, neanche
all'epoca. E' sempre stato meglio Eclipse con la sua plugin, piuttosto. Fai
tu :P
Le prima due le ho sentite nominare ma ho notato che la gente parlava
meglio di VSCode oggigiorno, quindi non mi sono neanche addentrato. Magari
avrei dovuto farlo?
|
|
Sembra che VSCode sia l'IDE del momento. Era da qualche annetto che il mondo open source implorava un editor ispirato a Sublime Text, ma che fosse gratuito e open, e Atom è stata la risposta che più gli si avvicinava, però è lento rispetto a ST (troppo lento per grossi progetti). E poi è arrivato VSCode! Non capisco bene come, ma nonostante usi anch'esso Electron (Chromium + Node.js/Javascript), proprio come Atom, al contrario di Atom è molto veloce e regge bene grossi progetti. In realtà ho dato una sbirciatina e mi pare di capire che il motivo risieda in una migliore architettura interna. Molti utenti di Sublime Text stanno passando a VSCode, e sembra che l'unico impedimento attuale sia la mancanza di questo o quell'latro plugin da cui uno può dipendere nel suo flusso di lavoro. VScode ha una GUI migliore, ed il vantaggio dell'essere completamente open source è punto fortissimo. Non ho provato a usare OCaml con ST, ma da quel poco che ho letto il supporto nativo è scarsino, ed esistono due packages per mettere le toppe a quei limiti. Ma non ho avuto l'impressione che siano stati investiti molti sforzi in quella direzione. Però ST è facilmente estensibile e personalizzabile. Al momento sto creando una sintassi Polygen. Non è ancora finita ma mi consente già di editare grammatiche con più agio che non in PolyGUI — nella sitnassi manca ancora l'implementazione delle Etichette ed i loro Selettori con punto, poi dovrò personalizzare un tema ad hoc, ed infine aggiungere funzionalità smart (shortcut per convertire selezioni in blocchi commento, snippet con i template base per una grammatica nuova, qualche funzione che converta caratteri illegali in Ascii escapes o entità XML, ecc.) e assicurarmi che la gestione dei simboli nell'autocompletamento funzioni bene. |
Come compilare Polygen per Windows senza la dipendenza da
cygwin1.dll.Cygwin vs MinGW
Sul Wiki di MinGW leggiamo (grassetto mio):
Lo stesso principio vale per MinGW-w64.
Questo thread su stackoverflow esamina i dettagli della questione:
https://stackoverflow.com/questions/187990/why-does-gcc-windows-depend-on-cygwin
In sintesi, se si compilasse Polygen usando MinGW-64 (GCC a 32 o 64 bit), l'exe finale non dipenderebbe da alcuna DLL (le librerie di MinGW-64 possono essere linkate staticamente).
Il problema è che sul sito MinGW-w64 non sono disponibili versioni per Windows che includano il supporto per OCaml. Però OCaml è disponibile in MSYS2:
https://github.com/Alexpux/MINGW-packages
mingw-w64-ocamlmingw-w64-ocaml-camlp4mingw-w64-ocaml-findlibmingw-w64-ocaml-lablgtkMSYS2 vs Cygwin
Dal Wiki di MSYS2 (grassetto mio):
Questo a conferma del fatto che MSYS2 consente la creazione di eseguibili che non necessitano di DLL per emulare il layer POSIX.
MSYS2 + MinGW-w64
Da quello che ho capito leggendo la documentazione di MSYS2, per creare eseguibili che non abbiano dipendenze da DLL, è necessario compilare con MinGW-64.
Praticamente MSYS2 offre diversi ambienti di sviluppo, alcuni dei quali legati al progetto MSYS2 stesso (e compilando in quell'ambiente si producono eseguibili che necessitano di DLL per il layer POSIX, come avviene con Cygwin), e infine vi sono gli ambienti MinGW-64 (a 32 o a 64 bit) che consentono invece di compilare eseguibili standalone che implementano il layer POSIX tramite Win API (e dipendono dalle varie DLL di MSVS, ormai presenti di default in tutte le versioni di Windows moderne).
Conclusioni
Concludendo, sarebbe utile a mio avviso considerare di appoaggiarsi a MSYS2 per future compilazioni di Polygen per Windows, e liberarsi della dipendenza da
cygwin1.dll. Quando la versione dicygwin1.dlldel sito Polygen.org ha semsso di funzionare con Win 7, non sono più stato in grado di usare Polygen per qualche anno; una seccatura.Stato compilabile dei sorgenti?
Io non ho avuto modo di testare quanto sopra. Sto valutando la possibilità di installare MSYS2 e fare un tentativo (sto solo verificando che non vi siano potenziali conflitti con altre applicazioni sulla mia macchina, ma sembra che MSYS operi in un ambiente completamente isolato).
Tu hai modo di confermarmi se il sorgente di Polygen è compilabile con la versione di OCaml che verrebbe installata da MSYS2? La v1.0.6 ha oltre 10, magari OCaml è cambiato nel frattempo. Vorrei evitare di installare MSYS2 (che mi pare di capire richiederà mezza giornata, tra settaggi, librerie e dipendenze, e cercare di capire come muovercisi dentro) solo per poi scoprire che i sorgenti attuali (quelli del repo, o quelli della v1.0.6) non possono compilare senza modifiche.
Che differenza c'è tra i sorgenti del repo (segnalati come v1.0.7) e quelli invece disponibili dal sito (1.0.6 del 2005)?
Mi sarebbe piaciuto testarlo in altri modi, ma come ti dissi il mio tentativo di installare OCaml (versione OCPWin, che contiene MinGW-w64) su Windows è stato disastroso: l'antivirus mi ha ranzato via 60% dei binari di OCaml. Le altre distribuzioni di OCaml per Win disponibili sono tutte basate su Cygwin, allora tanto vale installare MSYS2 e poi scaricare OCaml col suo package manager.
Purtroppo, anche i tentativi di cross compilare Polygen da Ubuntu tramite MinGW-w64 sono falliti — credo per via del fatto che il makefile andrebbe modificato per specificare di usare il crosscompilatore MinGW-w64 anziché il compilatore OCaml.
Link di Approfondimento
MinGW-w64
MSYS2
The text was updated successfully, but these errors were encountered: