3 %% Copyright (C) 1999-2007 Simone Piccardi. Permission is granted to copy,
4 %% distribute and/or modify this document under the terms of the GNU Free
5 %% Documentation License, Version 1.1 or any later version published by the
6 %% Free Software Foundation; with the Invariant Sections being "Un preambolo",
7 %% with no Front-Cover Texts, and with no Back-Cover Texts. A copy of the
8 %% license is included in the section entitled "GNU Free Documentation
12 \chapter{Gli strumenti di ausilio per la programmazione}
13 \label{cha:build_manage}
15 Tratteremo in questa appendice in maniera superficiale i principali strumenti
16 che vengono utilizzati per programmare in ambito Linux, ed in particolare gli
17 strumenti per la compilazione e la costruzione di programmi e librerie, e gli
18 strumenti di gestione dei sorgenti e di controllo di versione.
20 Questo materiale è ripreso da un vecchio articolo, ed al momento è molto
24 \section{L'uso di \texttt{make} per l'automazione della compilazione}
26 Il comando \texttt{make} serve per automatizzare il processo di costruzione di
27 un programma ed effettuare una compilazione intelligente di tutti i file
28 relativi ad un progetto software, ricompilando solo i file necessari ed
29 eseguendo automaticamente tutte le operazioni che possono essere necessarie
30 alla produzione del risultato finale.\footnote{in realtà \texttt{make} non si
31 applica solo ai programmi, ma in generale alla automazione di processi di
32 costruzione, ad esempio anche la creazione dei file di questa guida viene
33 fatta con \texttt{make}.}
36 \subsection {Introduzione a \texttt{make}}
38 Con \texttt{make} si possono definire i simboli del preprocessore C che
39 consentono la compilazione condizionale dei programmi (anche in Fortran); è
40 pertanto possibile gestire la ricompilazione dei programmi con diverse
41 configurazioni con la modifica di un unico file.
43 La sintassi normale del comando (quella che si usa quasi sempre, per le
44 opzioni vedere la pagina di manuale) è semplicemente \texttt{make}. Questo
45 comando esegue le istruzioni contenute in un file standard (usualmente
46 \texttt{Makefile}, o \texttt{makefile} nella directory corrente).
48 Il formato normale dei comandi contenuti in un \texttt{Makefile} è:
50 bersaglio: dipendenza1 dipendenza2 ...
55 dove lo spazio all'inizio deve essere un tabulatore (metterci degli spazi è un
56 errore comune, fortunatamente ben segnalato dalle ultime versioni del
57 programma), il bersaglio e le dipendenze nomi di file e le regole comandi di
60 Il concetto di base è che se uno dei file di dipendenza è più recente (nel
61 senso di tempo di ultima modifica) del file bersaglio quest'ultimo viene
62 ricostruito di nuovo usando le regole elencate nelle righe successive.
64 Il comando \texttt{make} ricostruisce di default il primo bersaglio che viene
65 trovato nella scansione del \texttt{Makefile}, se in un \texttt{Makefile} sono
66 contenuti più bersagli indipendenti, si può farne ricostruire un altro che non
67 sia il primo passandolo esplicitamente al comando come argomento, con qualcosa
68 del tipo di: \texttt{make altrobersaglio}.
70 Si tenga presente che le dipendenze stesse possono essere dichiarate come
71 bersagli dipendenti da altri file; in questo modo è possibile creare una
72 catena di ricostruzioni.
74 In esempio comune di quello che si fa è mettere come primo bersaglio il
75 programma principale che si vuole usare, e come dipendenze tutte gli oggetti
76 delle funzioni subordinate che utilizza, con i quali deve essere collegato; a
77 loro volta questi oggetti sono bersagli che hanno come dipendenza i relativi
78 sorgenti. In questo modo il cambiamento di una delle funzioni subordinate
79 comporta solo la ricompilazione della medesima e del programma finale.
82 \subsection{Utilizzo di \texttt{make}}
84 Il comando \texttt{make} mette a disposizione una serie molto complesse di
85 opzioni e di regole standard predefinite e sottintese, che permettono una
86 gestione estremamente rapida e concisa di progetti anche molto complessi; per
87 questo piuttosto che fare una replica del manuale preferisco commentare un
88 esempio di \texttt{makefile}, quello usato per ricompilare i programmi di
89 analisi dei dati dei test su fascio del tracciatore di Pamela.
93 #----------------------------------------------------------------------
95 # Makefile for a Linux System:
96 # use GNU FORTRAN compiler g77
97 # Makefile done for tracker test data
99 #----------------------------------------------------------------------
102 FFLAGS= -fvxt -fno-automatic -Wall -O6 -DPC # -DDEBUG
107 # FC Fortran compiler for standard rules
108 # FFLAGS Fortran flags for standard rules
109 # CC C Compiler for standard rules
110 # CFLAGS C compiler flags for standard rules
111 LIBS= -L/cern/pro/lib -lkernlib -lpacklib -lgraflib -lmathlib
112 OBJ=cnoise.o fit2.o pedsig.o loop.o badstrp.o cutcn.o readevnt.o \
113 erasepedvar.o readinit.o dumpval.o writeinit.o
115 riduzione: riduzione.F $(OBJ) commondef.f readfile.o
116 $(FC) $(FFLAGS) -o riduzione riduzione.F readfile.o $(OBJ) $(LIBS)
118 readfile.o: readfile.c
119 $(CC) $(CFLAGS) -o readfile.o readfile.c
133 Anzitutto i commenti, ogni linea che inizia con un \texttt{\#} è un
134 commento e non viene presa in considerazione.
136 Con \texttt{make} possono essere definite delle variabili, da potersi riusare
137 a piacimento, per leggibilità si tende a definirle tutte maiuscole,
138 nell'esempio ne sono definite varie: \small
141 FFLAGS= -fvxt -fno-automatic -Wall -O6 -DPC # -DDEBUG
146 LIBS= -L/cern/pro/lib -lkernlib -lpacklib -lgraflib -lmathlib
147 OBJ=cnoise.o fit2.o pedsig.o loop.o badstrp.o cutcn.o readevnt.o \
151 La sintassi è \texttt{NOME=}, alcuni nomi però hanno un significato speciale
152 (nel caso \texttt{FC}, \texttt{FLAGS}, \texttt{CC}, \texttt{CFLAGS}) in quanto
153 sono usati da \texttt{make} nelle cosiddette \textsl{regole implicite} (su cui
156 Nel caso specifico, vedi anche i commenti, abbiamo definito i comandi di
157 compilazione da usare per il C e il Fortran, e i rispettivi flag, una variabile
158 che contiene il pathname e la lista delle librerie del CERN e una variabile con una
159 lista di file oggetto.
161 Per richiamare una variabile si usa la sintassi \texttt{\$(NOME)}, ad esempio
162 nel makefile abbiamo usato:
164 $(FC) $(FFLAGS) -o riduzione riduzione.F readfile.o $(OBJ) $(LIBS)
166 e questo significa che la regola verrà trattata come se avessimo scritto
167 esplicitamente i valori delle variabili.
169 Veniamo ora alla parte principale del makefile che esegue la costruzione del
172 riduzione: riduzione.F $(OBJ) commondef.f readfile.o
173 $(FC) $(FFLAGS) -o riduzione riduzione.F readfile.o $(OBJ) $(LIBS)
174 readfile.o: readfile.c
175 $(CC) $(CFLAGS) -o readfile.o readfile.c
179 Il primo bersaglio del makefile, che definisce il bersaglio di default, è il
180 programma di riduzione dei dati; esso dipende dal suo sorgente da tutti gli
181 oggetti definiti dalla variabile \texttt{OBJ}, dal file di definizioni
182 \texttt{commondef.f} e dalla routine C \texttt{readfile.o}; si noti il
183 \texttt{.F} del sorgente, che significa che il file prima di essere compilato
184 viene fatto passare attraverso il preprocessore C (cosa che non avviene per i
185 \texttt{.f}) che permette di usare i comandi di compilazione condizionale del
186 preprocessore C con la relativa sintassi. Sotto segue il comando di
187 compilazione che sfrutta le variabili definite in precedenza per specificare
188 quale compilatore e opzioni usare e specifica di nuovo gli oggetti e le
191 Il secondo bersaglio definisce le regole per la compilazione della routine
192 in C; essa dipende solo dal suo sorgente. Si noti che per la compilazione
193 vengono usate le variabili relative al compilatore C. Si noti anche che se
194 questa regola viene usata, allora lo sarà anche la precedente, dato che
195 \texttt{riduzione} dipende da \texttt{readfile.o}.
197 Il terzo bersaglio è apparentemente incomprensibile dato che vi compare
198 solo il riferimento alla variabile \texttt{OBJ} con una sola dipendenza e
199 nessuna regola, essa però mostra le possibilità (oltre che la
200 complessità) di \texttt{make} connesse alla presenza di quelle regole
201 implicite a cui avevamo accennato.
203 Anzitutto una peculiarità di \texttt{make} è che si possono anche usare più
204 bersagli per una stessa regola (nell'esempio quelli contenuti nella variabile
205 \texttt{OBJ} che viene espansa in una lista); in questo caso la regola di
206 costruzione sarà applicata a ciascuno che si potrà citare nella regola stessa
207 facendo riferimento con la variabile automatica: \texttt{\$@}. L'esempio
208 usato per la nostra costruzione però sembra non avere neanche la regola di
211 Questa mancanza sia di regola che di dipendenze (ad esempio dai vari sorgenti)
212 illustra le capacità di funzionamento automatico di \texttt{make}.
213 Infatti è facile immaginarsi che un oggetto dipenda da un sorgente, e che
214 per ottenere l'oggetto si debba compilare quest'ultimo.
216 Il comando \texttt{make} sa tutto questo per cui quando un bersaglio è un
217 oggetto (cioè ha un nome tipo \texttt{qualcosa.o}) non è necessario
218 specificare il sorgente, ma il programma lo va a cercare nella directory
219 corrente (ma è possibile pure dirgli di cercarlo altrove, il caso è trattato
220 nel manuale). Nel caso specifico allora si è messo come dipendenza solo il
221 file delle definizioni che viene incluso in ogni subroutine.
223 Inoltre come dicevamo in genere per costruire un oggetto si deve compilarne il
224 sorgente; \texttt{make} sa anche questo e sulla base dell'estensione del
225 sorgente trovato (che nel caso sarà un \texttt{qualcosa.f}) applica la regola
226 implicita. In questo caso la regola è quella di chiamare il compilatore
227 fortran applicato al file oggetto e al relativo sorgente, questo viene fatto
228 usando la variabile \texttt{FC} che è una delle variabili standard usata dalle
229 regole implicite (come \texttt{CC} nel caso di file \texttt{.c}); per una
230 maggiore flessibilità poi la regola standard usa anche la variabile
231 \texttt{FFLAGS} per specificare, a scelta dell'utente che non ha che da
232 definirla, quali flag di compilazione usare (nella documentazione sono
233 riportate tutte le regole implicite e le relative variabili usate).
235 In questo modo è stato possibile usare una sola riga per indicare la serie di
236 dipendenze e relative compilazioni delle singole subroutine; inoltre con l'uso
237 della variabile \texttt{OBJ} l'aggiunta di una nuova eventuale routine
238 \texttt{nuova.f} comporta solo l'aggiunta di \texttt{nuova.o} alla definizione
242 \section{Cuncurrent Version System -- CVS}
244 Il programma CVS è un sistema di archiviazione dei programmi che consente di
245 tenere traccia di tutte le modifiche e di condividere un archivio comune per
246 progetti portati avanti da diverse persone.
248 \subsection{Introduzione}
249 CVS è basato sul concetto di repositorio, un archivio in cui vengono riposti
250 e da cui vengono presi i sorgenti dei programmi. L'archivio tiene traccia delle
251 diverse versioni registrate; i programmatori inviano le modifiche usando una
252 copia locale che hanno nella loro directory di lavoro.
254 CVS può gestire più di un progetto, esso organizza i progetti in
255 \textsl{moduli} identificati dal nome della directory in cui sono messi i file
256 relativi, ad esempio:
259 [piccardi@pcpamela ~]$ ls /usr/local/cvsroot/
260 CVSROOT adidsp geometry muonacq pamela
263 in questo caso si hanno i moduli \texttt{adidsp geometry muonacq pamela}; un
264 utente potrà recuperare tutti i file relativi al modulo \texttt{pamela} che
265 andaranno nella directory \texttt{pamela}; è anche possibile gestire una
266 gerarchia di moduli, inseriti in un albero di directory.
268 CVS ha una directory base dove tiene gli archivi (che nel è appunto
269 \texttt{/usr/local/cvsroot}) e i vari file amministrativi; ogni progetto deve
270 fare riferimento ad essa; in un progetto attivo essa viene memorizzata nei
271 file amministrativi locali del progetto (ad esempio per un utente che ha il
272 progetto \texttt{muonacq} nella sua home directory sarà in
273 \texttt{\tild/muonacq/CVS}) e non è necessario specificarla; in generale essa
274 viene tenuta dalla variabile di shell \texttt{CVSROOT} (inizializzata allo
275 startup), o specificata direttamente dall'utente con l'apposita opzione
276 \texttt{-d} (ex. \texttt{cvs -d /usr/local/cvsroot comando opzioni}).
278 Normalmente l'archivio si tiene su una macchina remota e vi si accede via
279 rete. Per repositori esterni esistono varie modalità di accesso, la via più
280 semplice è quella dell'uso di \texttt{ssh} come rimpiazzo di \texttt{rsh} per
281 l'accesso esterno; in tal caso la directory del repositorio si può accedere
282 con la sintassi: \small
284 cvs -d :ext:utente@server:/usr/local/cvsroot comando
288 questo però comporta che sulla macchina remota \texttt{server} sia installato
289 il server \texttt{ssh} ed esista l'utente \texttt{utente} con privilegi di
290 accesso ai file; inoltre sulla macchina ospite deve esser stata definita la
291 variabile di shell \texttt{CVS\_RSH=ssh}.
293 In questo modo ssh si collega alla macchina remota ed esegue il comando CVS con
294 una connessione criptata dopo aver richiesto la password di \texttt{utente}.
297 \subsection{Utilizzo di \texttt{cvs}}
299 Per creare un repositorio a partire da un gruppo di programmi esistente basta
300 dare il comando \texttt{cvs import project tag release} nella directory dei
301 sorgenti; verrà creato nel repositorio il modulo di nome \texttt{project} a
302 cui poi si potrà accedere con i successivi comandi; \texttt{tag} è una
303 etichetta di versione iniziale (ex. \texttt{1.1.1}) dato a tutto il blocco e
304 \texttt{release} una etichetta di versione data ai programmi.
306 Una volta creato il repositorio è d'uopo cancellare la directory e ripartire
307 dal progetto appena creato. Per recuperare ex-novo tutti i file di un progetto
308 il comando da dare è:
311 cvs [-d ...] checkout project [-r rel] [-D date]
313 \normalsize che creerà la directory \texttt{project} nella directory corrente
314 con l'ultima versione dei file archiviata; se non si vuole la versione più
315 aggiornata, ma una versione precedente si può usare l'opzione \texttt{-r} che
316 scaricherà la versione identificata dall'etichetta specificata (vedi la parte
317 seguente sul comando \texttt{tag}) o l'opzione \texttt{-D} che scaricherà la
318 versione più recente prima della data specificata.
320 Una volta scaricato il progetto è possibile evitare di specificare la
321 directory base del repositorio con l'opzione \texttt{-d} qualora i comandi
322 vengano dati all'interno della directory creata, essa viene tenuta nel file
323 \texttt{CVS/Root}, e può essere cambiata (qualora si usino più repositori)
326 Una volta creata la propria copia locale dei programmi, è possibile lavorare
327 su di essi stando nella relativa directory,
328 e apportare tutte le modifiche che si vogliono; due comandi
329 permettono di schedulare la rimozione o l'aggiunta di file al repositorio:
336 ma niente viene modificato nel repositorio fintanto che non viene dato il
337 comando \texttt{commit}:
342 (è possibile mandare le modifiche anche per il singolo file).
344 Questi comandi comunque non effettuano le modifiche se i file del repositorio
345 nel frattempo sono stati modificati; in questo caso rilevano le differenze e
346 restituiscono un \textit{merging} delle versioni locale/globale nella
347 directory di lavoro, che è compito del programmatore esaminare per eliminare
350 Per esempio viene eseguito un commit su una versione già modificata da un
351 altro sul repositorio, il programma segnalerà che c'è un conflitto e
352 chiederà al ``committente'' di intervenire sui file per i quali sono stati
353 rilevati i conflitti .
355 Le sezioni di codice in conflitto sono separate come:
358 $(CC) $(CFLAGS) -o pamacq pamacq.c -lm
360 $(CC) $(CFLAGS) -o pamacq pamacq.c
364 nel caso si c'è stata una modifica sul file (mostrata nella parte superiore)
365 incompatibile con quella fatta nel repositorio (mostrata nella parte
366 inferiore). Prima di eseguire un \textit{commit} occorre pertanto integrare le
367 modifiche e salvare nuovamente il file; a questo punto il \textit{commit} diventa
370 \subsection{I principali sotto comandi}
372 I principali sotto-comandi di \texttt{cvs} utilizzati per controllare lo stato
376 \item \texttt{cvs update} \\
377 scarica le eventuali modifiche dei file del repositorio e le applica ai file
378 nella directory corrente. In caso di conflitti con modifiche locali effettua
379 un \textit{merging} con le caratteristiche esposte in precedenza.
381 \item \texttt{cvs status} \\
382 compara i file nella directory locale con quelli del repositorio e stampa a
383 schermo le informazioni di stato di ciascuno di essi:
385 \item \texttt{Locally Modified} il file è stato modificato localmente
386 \item \texttt{Locally Added} il file è stato aggiunto localmente
387 \item \texttt{Up to date} il file è identico
388 \item \texttt{Needs Patch} il file è cambiato sul repositorio (va aggiornato)
389 \item \texttt{Needs Merge} il file è cambiato sul repositorio e localmente, le
390 differenze vanno riunite prima del commit, in genere basta un \texttt{cvs
391 update}, ma in caso di conflitti questi vanno sanati.
395 \item \texttt{cvs log} \\
396 legge il giornale del modulo corrente; in questo modo si hanno le
397 informazioni sullo stato del progetto all'interno del repositorio, per
398 ciascun file è vengono mostrati informazioni generali su:
400 \item release attuale
401 \item presenza di eventuali ramificazioni
402 \item lista di etichette simboliche
403 \item i messaggi di commento salvati ad ogni \textit{commit}
406 \item \texttt{cvs rtag Etichetta modulo} \\
407 permette di associare una etichetta alla corrente versione dei file nel
408 progetto così come sono nel repositorio; in modo da poter ritornare a quello
409 stato del software con il comando \texttt{cvs checkout -r Etichetta module}.
413 %TODO mettere SVN al posto di CVS
416 % LocalWords: make Makefile makefile shell FC FLAGS CFLAGS pathname CERN
417 % LocalWords: OBJ commondef readfile FFLAGS Cuncurrent Version System CVS home
418 % LocalWords: adidsp geometry muonacq andaranno CVSROOT startup cvs ssh rsh to
419 % LocalWords: project tag Root commit update merging Locally Modified Added
420 % LocalWords: Needs Patch Merge log rtag checkout module altrobersaglio
427 %%% TeX-master: "gapil"