[Dlab-devel] Progetto Ice-Breaker

[Bernardo I. <be...@co...>]

Ciao a tutti,

ecco un po' di documentazione preliminare sul progetto che Alexio dovra'
affrontare nei prossimi giorni. Leggetelo tutti perche' e' importante
seguire questa fase mentre si svolge.

Siete tutti invitati a rispondere a questa mail con commenti, critiche,
domande, etc.

-------------------------------------------------------------------------



Progetto 'Ice-Breaker'
**********************


0. Scopo
--------

Creare una infrastruttura coerente e comprensibile da utilizzare come
punto di partenza per gli sviluppi successivi.

Durante questo lavoro verranno affrontati per la prima volta i problemi
legati all'uso dei tool di sviluppo, in modo che gli altri programmatori
non debbano risolverli individualmente durante le fasi successive.

Un altro obiettivo non meno importante e' la definizione di uno stile
di programmazione e documentazione comune a tutti i moduli del progetto.


1. Fase 1: Setup ambiente di sviluppo
-------------------------------------

In questa fase saranno installati i seguenti software:

   - compilatore (gcc, GNU make, linker, etc.)
   - editor (UltraEdit, vim o altro)
   - SDL (libreria, documentazione e sorgenti)
   - liberie accessorie (SDL_mixer, SDL_image, etc.)
   - CVS (WinCVS e/o TortuiseCVS)

 Oltre ad _installare_ i suddetti strumenti, si devono trovare e
documentare dei metodi per semplificare il lavoro degli altri
programmatori.

 Per esempio, sara' necessario inserire la directory 'bin/' del gcc
nel path di Windows (usando le impostazioni di sistema su Windows
NT/2000 e l'autoexec.bat in Win 9x/ME). Potrebbe essere utile
creare un batch del DOS da lanciare all'avvio della finestra per
attivare alcune caratteristiche utili (DOSKEY, directory corrente,
etc.).

 Per quanto riguarda l'editor, sara' necessario cambiare la
configurazione standard con una piu' adatta allo sviluppo in C.
L'UltraEdit permette di aggiungere delle macro nei menu: potremmo
sfruttare questa feature per eseguire la compilazione direttamente
dall'editor. Mi risulta inoltre che l'UltraEdit abbia dei moduli
per l'integrazione con alcuni ambienti di sviluppo comuni. E'
probabile che esista qualcosa di gia' pronto per il gcc, o che sia
facile adattarne uno esistente al gcc.

 Il kit di sviluppo dell'SDL deve essere installato in modo che sia
possibile includere gli header e linkare con la lib senza dover
specificare dei path nei sorgenti. Un metodo piuttosto rozzo consiste
nel copiare gli include nella directory 'include/' del mingw e la
SDL.lib nella directory 'lib/'. Se fosse possible, sarebbe meglio:

   - settare due variabili di ambiente nel DOS

         set SDL_INCLUDE=C:\pippo\pluto\SDL\include
	 set SDL_LIB=C:\pippo\pluto\SDL\lib

   - usare queste variabili nel Makefile per specificare il path
     che il compilatore deve usare quando compila e quando linka:

         CFLAGS = -I $(SDL_INCLUDE)
	 LDFLAGS = -L $(SDL_LIB)

     (-I e -L sono due opzioni del gcc che aggiungono, rispettivamente,
     un path per gli Include e uno per le Librerie).


 La SDL_image e la SDL_mixer sono librerie accessorie dell'SDL che si
possono scaricare dal sito ufficiale (http://www.libsdl.org/). La prima
offre delle funzioni utili per caricare/salvare/processare immagini di
vari formati (GIF, JPEG, TIFF, etc.). La seconda permette invece di
caricare e riprodurre vari tipi di file audio (WAVE, MPEG-3, MIDI, moduli
S3M o XM, etc.).

 Esistono anche sono altre librerie utili sul sito della SDL, per esempio
la SDL_ttf, che cestisce l'uso dei font TrueType. Sarebbe utile individuare
quali di queste librerie potrebbe rivalrsi utile durante lo sviluppo e
sperimentare un po' per valutarne il grado di usabilita'.

 Per quanto riguarda il CVS, esistono due diversi client per Windows.
WinCVS ha un'interfaccia grafica e permette di effettuare tutte le operazioni
piu' arcane previste dal CVS. TortuiseCVS invece e' integrato con Explorer e
permette di eseguire alcune operazioni comuni (checkout, update, add, commit...)
usando il menu contestuale delle icone (quello che si apre con il tasto
destro, per intenderci). Questo modo di lavorare copre probabilmente il 90%
delle nostre necessita' ed e' piu' pratico rispetto a WinCVS.

 Il firewall della scuola ci dara' senz'altro dei problemi. Ho visto che
WinCVS permette di specificare un server proxy. Non credo sia possibile usarlo
insieme all'SSH, ma ho verificato che e' possibile accedere al nostro
repositorio CVS su SourceForge anche senza SSH, usando il metodo "pserver".

 La documentazione di WinCVS e' piuttosto esauriente e si puo' scaricare in
PDF direttamente dal sito del progetto su SourceForge:
http://www.sourceforge.net/projects/cvsgui/.

 Sempre su SourceForge, trovate i "site docs" che spiegano, tra le altre cose,
come utilizzare il CVS del nostro progetto. C'e' scritto di usare l'SSH, ma
come ho gia' detto pare che funzioni anche senza.

 Provate a fare un checkout del repositorio: vi verra' scaricata una directory
vuota. In questa directory, potete aggiungere un file di prova e fare l'add
nel repositorio per vedere se funziona. Dopo gli esperimenti ricordatevi di
cancellare tutto!


2. Fase 2: Creazione di un Makefile
-----------------------------------

E' necessario creare un semplice Makefile per compilare e linkare 2-3 sorgenti C
di prova. La documentazione dello GNU make dovrebbe essere inclusa in formato HTML
nel pacchetto mingw, ma si tratta di un manuale prolisso che spiega numerosi
dettagli che per noi sono superflui.

Consiglio quindi un approccio da "smanettone": prendiamo i sorgenti di un piccolo
progetto SDL scritto con il mingw e andiamo a vedere come e' fatto il Makefile.
Con tutta probabilita', sara' approssimativamente cio' di cui avevamo bisogno noi.

Se il Makefile e' corretto, bastera' scrivere "make" dalla linea di comando e
tutto il progetto si compilera' automaticamente senza ulteriori interventi manuali.


------------------------------------

La fase 3 consiste nella creazione dei moduli principali del gioco. Non ho ancora
finito di mettere a pulito gli appunti che ho scritto ieri. Per oggi mi sembra che
ci sia abbastanza materiale su cui lavorare. Entro domani vedro' di postare il
resto delle linee guida nella mailing list.


Mi raccomando, e' importante che rimanga una traccia di cio' che e' stato fatto
per arrivare ad un ambiente di sviluppo funzionante. Non importa che sia un
manuale di riferimento pronto per la pubblicazione: e' sufficiente postare qualche
nota informale sulla mailing list. L'importante e' che la procedura da seguire sia
chiara per tutti e magari anche motivata (es: "si fa cosi' perche' altrimenti
succede questo e quello").


Buon lavoro!

-- 
  // Bernardo Innocenti - Develer S.r.l., R&D dept.
\X/  http://www.develer.com/