Filippo Biondi ha scritto:
Il giorno mer, 09-02-2005 alle 09:43 +0100, Stefano Rosanelli ha
scritto:
KDevelop utilizza gli autotools per creare progetti [i malefici autoconf
e automake], sono loro che usano una marea di files....
Ah ecco i colpevoli!!
Se vuoi sfuggire dai malefici autotools ti posso consigliare SCons
[www.scons.org] che uso con soddisfazione da tempo [anche insieme a
KDevelop].
Mi permetto di dissentire: scons ha i suoi aspetti interessanti ed è
alquanto promettente, ma è assai immaturo. Ne fa fede la scarsa
diffusione, nel senso che sono pochi i progetti open source che lo
propongono come sistema di build. Può darsi che tra un paio d'anni le
cose cambino (magari python potrà essere dato per installato, così come
gli autotools fanno per una sh), così come oggigiorno Postfix si può
considerare adeguatamente rodato per sostituire sendmail.
L'ultima volta che ci ho guardato, tuttavia, per i miei gusti SCons
aveva alcuni fondamentali problemi progettuali:
1 - i build file sono programmi (Python);
2 - per fare qualcosa di imprevisto (in termini SCons, creare un
nuovo builder) devo scrivere qualcosa in Python.
Nel punto (1) il problema non è tanto Python ma il fatto che il build
file diventa un programma e, come tale, soggetto alla "maledizione di
Turing": diventa potenzialmente molto difficile fare qualcosa che non
sia scriverlo ed eseguirlo. In particolare, diventa potenzialmente
molto difficile scrivere un altro programma che lo esamina, stabilisce
se è corretto, lo manipola e così via - tutte cose che invece con i
Makefile si fanno perchè i Makefile non sono un linguaggio di
programmazione, sono un elenco di vincoli (mi si potrebbe obiettare
che anche un Makefile può essere Turing-completo usando i conditionals,
ma ciò va a demerito di make, e SCons venendo dopo poteva evitare questo
errore).
Per il punto (2) il problema è che invece di avere un approccio
orientato al riuso, ovvero "uso make fin dove arriva make e uso la shell
come colla dei noti tool Unix laddove make non arriva", ho un approccio
orientato alla riscrittura: quel che manca va scritto (in Python). Mi
rendo ben conto che chi opera in un ambiente impoverito come Windows
possa considerare vantaggioso poter compilare software senza rimediare
alle deficienze del proprio sistema, soprattutto a causa della
consapevolezza che più software si installa meno Windows funziona, ma
non vedo il motivo di infliggere tali insensatezze ad ambienti che se le
erano lasciate alle spalle prima che Windows venisse progettato.
Davide Bolcioni
--
There is no place like /home.
|