build.tex

   1 %% build.tex
   2 %%
   3 %% Copyright (C) 1999-2010 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
   9 %% License".
  10 %%
  11
  12 \chapter{Gli strumenti di ausilio per la programmazione}
  13 \label{cha:build_manage}
  14
  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.
  19
  20 Questo materiale è ripreso da un vecchio articolo, ed al momento è molto
  21 obsoleto.
  22
  23
  24 \section{L'uso di \texttt{make} per l'automazione della compilazione}
  25
  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}.}
  34
  35
  36 \subsection {Introduzione a \texttt{make}}
  37
  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.
  42
  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).
  47
  48 Il formato normale dei comandi contenuti in un \texttt{Makefile} è:
  49 \begin{verbatim}
  50 bersaglio: dipendenza1 dipendenza2 ...
  51         regola1
  52         regola2
  53         ...
  54 \end{verbatim}
  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
  58 shell.
  59
  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.
  63
  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}.
  69
  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.
  73
  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.
  80
  81
  82 \subsection{Utilizzo di \texttt{make}}
  83
  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.
  90
  91 \small
  92 \begin{verbatim}
  93 #----------------------------------------------------------------------
  94 #
  95 # Makefile for a Linux System:
  96 # use GNU FORTRAN compiler g77
  97 # Makefile done for tracker test data
  98 #
  99 #----------------------------------------------------------------------
 100 # Fortran flags
 101 FC=g77
 102 FFLAGS= -fvxt -fno-automatic -Wall -O6 -DPC # -DDEBUG
 103 CC=gcc
 104 CFLAGS= -Wall -O6
 105 CFLADJ=-c #-DDEBUG
 106 #
 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
 114
 115 riduzione: riduzione.F $(OBJ) commondef.f readfile.o
 116         $(FC) $(FFLAGS) -o riduzione riduzione.F readfile.o $(OBJ) $(LIBS)
 117
 118 readfile.o: readfile.c
 119         $(CC) $(CFLAGS) -o readfile.o readfile.c
 120
 121 $(OBJ): commondef.f
 122
 123 .PHONY : clean
 124 clean:
 125         rm -f *.o
 126         rm -f *~
 127         rm -f riduzione
 128         rm -f *.rz
 129         rm -f output
 130 \end{verbatim}
 131 \normalsize
 132
 133 Anzitutto i commenti, ogni linea che inizia con un \texttt{\#} è un
 134 commento e non viene presa in considerazione.
 135
 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
 139 \begin{verbatim}
 140 FC=g77
 141 FFLAGS= -fvxt -fno-automatic -Wall -O6 -DPC # -DDEBUG
 142 CC=gcc
 143 CFLAGS= -Wall -O6
 144 CFLADJ=-c #-DDEBUG
 145 ...
 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 \
 148 \end{verbatim}
 149 \normalsize
 150
 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
 154 torneremo dopo).
 155
 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.
 160
 161 Per richiamare una variabile si usa la sintassi \texttt{\$(NOME)}, ad esempio
 162 nel makefile abbiamo usato:
 163 \begin{verbatim}
 164         $(FC) $(FFLAGS) -o riduzione riduzione.F readfile.o $(OBJ) $(LIBS)
 165 \end{verbatim}
 166 e questo significa che la regola verrà trattata come se avessimo scritto
 167 esplicitamente i valori delle variabili.
 168
 169 Veniamo ora alla parte principale del makefile che esegue la costruzione del
 170 programma:
 171 \begin{verbatim}
 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
 176 $(OBJ): commondef.f
 177 \end{verbatim}
 178
 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
 189 librerie.
 190
 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}.
 196
 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.
 202
 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
 209 costruzione.
 210
 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.
 215
 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.
 222
 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).
 234
 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
 239 di \texttt{OBJ}.
 240
 241
 242 \section{Cuncurrent Version System -- CVS}
 243
 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.
 247
 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.
 253
 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:
 257 \small
 258 \begin{verbatim}
 259 [piccardi@pcpamela ~]$ ls /usr/local/cvsroot/
 260 CVSROOT  adidsp  geometry  muonacq  pamela
 261 \end{verbatim}
 262 \normalsize %$
 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.
 267
 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}).
 277
 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
 283 \begin{verbatim}
 284 cvs -d :ext:utente@server:/usr/local/cvsroot comando
 285 \end{verbatim}
 286 \normalsize
 287
 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}.
 292
 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}.
 295
 296
 297 \subsection{Utilizzo di \texttt{cvs}}
 298
 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.
 305
 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 è:
 309 \small
 310 \begin{verbatim}
 311 cvs [-d ...] checkout project [-r rel] [-D date]
 312 \end{verbatim}
 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.
 319
 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)
 324 editando detto file.
 325
 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:
 330 \small
 331 \begin{verbatim}
 332 cvs add file1.c
 333 cvs remove file2.c
 334 \end{verbatim}
 335 \normalsize
 336 ma niente viene modificato nel repositorio fintanto che non viene dato il
 337 comando \texttt{commit}:
 338 \small
 339 \begin{verbatim}
 340 cvs commit [file]
 341 \end{verbatim}
 342 (è possibile mandare le modifiche anche per il singolo file).
 343
 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
 348 eventuali contrasti.
 349
 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 .
 354
 355 Le sezioni di codice in conflitto sono separate come:
 356 \begin{verbatim}
 357 <<<<<<< Makefile
 358         $(CC) $(CFLAGS) -o pamacq pamacq.c -lm
 359 =======
 360         $(CC) $(CFLAGS) -o pamacq pamacq.c
 361
 362 >>>>>>> 1.22
 363 \end{verbatim}
 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
 368 possibile.
 369
 370 \subsection{I principali sotto comandi}
 371
 372 I principali sotto-comandi di \texttt{cvs} utilizzati per controllare lo stato
 373 dei sorgenti sono:
 374
 375 \begin{itemize}
 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.
 380
 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:
 384 \begin{itemize}
 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.
 392
 393 \end{itemize}
 394
 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:
 399 \begin{itemize}
 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}
 404 \end{itemize}
 405
 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}.
 410
 411 \end{itemize}
 412
 413 %TODO mettere SVN al posto di CVS
 414
 415
 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
 421 % LocalWords:
 422
 423
 424
 425 %%% Local Variables:
 426 %%% mode: latex
 427 %%% TeX-master: "gapil"
 428 %%% End: