build.tex

   1 %% build.tex
   2 %%
   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
   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 la compilazione}
  25
  26 Il comando \texttt{make} serve per effettuare una compilazione intelligente di
  27 tutti i file relativi a un programma (corpo principale, funzioni ausiliarie,
  28 librerie collegate, ecc.)  ricompilando solo i file necessari.
  29
  30 \subsection {Introduzione a \texttt{make}}
  31
  32 Con \texttt{make} si possono definire i simboli del preprocessore C che
  33 consentono la compilazione condizionale dei programmi (anche in Fortran); è
  34 pertanto possibile gestire la ricompilazione dei programmi con diverse
  35 configurazioni con la modifica di un unico file.
  36
  37 La sintassi normale del comando (quella che si usa quasi sempre, per le
  38 opzioni vedere la pagina di manuale) è semplicemente \texttt{make}. Questo
  39 comando esegue le istruzioni contenute in un file standard (usualmente
  40 \texttt{Makefile}, o \texttt{makefile} nella directory corrente).
  41
  42 Il formato normale dei comandi contenuti in un \texttt{Makefile} è:
  43 \begin{verbatim}
  44 bersaglio: dipendenza1 dipendenza2 ...
  45         regola1
  46         regola2
  47         ...
  48 \end{verbatim}
  49 dove lo spazio all'inizio deve essere un tabulatore (metterci degli spazi è un
  50 errore comune, fortunatamente ben segnalato dalle ultime versioni del
  51 programma), il bersaglio e le dipendenze nomi di file e le regole comandi di
  52 shell.
  53
  54 Il concetto di base è che se uno dei file di dipendenza è più recente (nel
  55 senso di tempo di ultima modifica) del file bersaglio quest'ultimo viene
  56 ricostruito di nuovo usando le regole elencate nelle righe successive.
  57
  58 Il comando \texttt{make} ricostruisce di default il primo bersaglio che viene
  59 trovato nella scansione del \texttt{Makefile}, se in un \texttt{Makefile} sono
  60 contenuti più bersagli indipendenti, si può farne ricostruire un altro che non
  61 sia il primo passandolo esplicitamente al comando come argomento, con qualcosa
  62 del tipo di: \texttt{make altrobersaglio}.
  63
  64 Si tenga presente che le dipendenze stesse possono essere dichiarate come
  65 bersagli dipendenti da altri file; in questo modo è possibile creare una
  66 catena di ricostruzioni.
  67
  68 In esempio comune di quello che si fa è mettere come primo bersaglio il
  69 programma principale che si vuole usare, e come dipendenze tutte gli oggetti
  70 delle funzioni subordinate che utilizza, con i quali deve essere collegato; a
  71 loro volta questi oggetti sono bersagli che hanno come dipendenza i relativi
  72 sorgenti. In questo modo il cambiamento di una delle funzioni subordinate
  73 comporta solo la ricompilazione della medesima e del programma finale.
  74
  75
  76 \subsection{Utilizzo di \texttt{make}}
  77
  78 Il comando \texttt{make} mette a disposizione una serie molto complesse di
  79 opzioni e di regole standard predefinite e sottintese, che permettono una
  80 gestione estremamente rapida e concisa di progetti anche molto complessi; per
  81 questo piuttosto che fare una replica del manuale preferisco commentare un
  82 esempio di \texttt{makefile}, quello usato per ricompilare i programmi di
  83 analisi dei dati dei test su fascio del tracciatore di Pamela.
  84
  85 \small
  86 \begin{verbatim}
  87 #----------------------------------------------------------------------
  88 #
  89 # Makefile for a Linux System:
  90 # use GNU FORTRAN compiler g77
  91 # Makefile done for tracker test data
  92 #
  93 #----------------------------------------------------------------------
  94 # Fortran flags
  95 FC=g77
  96 FFLAGS= -fvxt -fno-automatic -Wall -O6 -DPC # -DDEBUG
  97 CC=gcc
  98 CFLAGS= -Wall -O6
  99 CFLADJ=-c #-DDEBUG
 100 #
 101 # FC            Fortran compiler for standard rules
 102 # FFLAGS        Fortran flags for standard rules
 103 # CC            C Compiler for standard rules
 104 # CFLAGS        C compiler flags for standard rules
 105 LIBS=  -L/cern/pro/lib -lkernlib -lpacklib -lgraflib -lmathlib
 106 OBJ=cnoise.o fit2.o pedsig.o loop.o badstrp.o cutcn.o readevnt.o \
 107 erasepedvar.o readinit.o dumpval.o writeinit.o
 108
 109 riduzione: riduzione.F $(OBJ) commondef.f readfile.o
 110         $(FC) $(FFLAGS) -o riduzione riduzione.F readfile.o $(OBJ) $(LIBS)
 111
 112 readfile.o: readfile.c
 113         $(CC) $(CFLAGS) -o readfile.o readfile.c
 114
 115 $(OBJ): commondef.f
 116
 117 .PHONY : clean
 118 clean:
 119         rm -f *.o
 120         rm -f *~
 121         rm -f riduzione
 122         rm -f *.rz
 123         rm -f output
 124 \end{verbatim}
 125 \normalsize
 126
 127 Anzitutto i commenti, ogni linea che inizia con un \texttt{\#} è un
 128 commento e non viene presa in considerazione.
 129
 130 Con \texttt{make} possono essere definite delle variabili, da potersi riusare
 131 a piacimento, per leggibilità si tende a definirle tutte maiuscole,
 132 nell'esempio ne sono definite varie: \small
 133 \begin{verbatim}
 134 FC=g77
 135 FFLAGS= -fvxt -fno-automatic -Wall -O6 -DPC # -DDEBUG
 136 CC=gcc
 137 CFLAGS= -Wall -O6
 138 CFLADJ=-c #-DDEBUG
 139 ...
 140 LIBS=  -L/cern/pro/lib -lkernlib -lpacklib -lgraflib -lmathlib
 141 OBJ=cnoise.o fit2.o pedsig.o loop.o badstrp.o cutcn.o readevnt.o \
 142 \end{verbatim}
 143 \normalsize
 144
 145 La sintassi è \texttt{NOME=}, alcuni nomi però hanno un significato speciale
 146 (nel caso \texttt{FC}, \texttt{FLAGS}, \texttt{CC}, \texttt{CFLAGS}) in quanto
 147 sono usati da \texttt{make} nelle cosiddette \textsl{regole implicite} (su cui
 148 torneremo dopo).
 149
 150 Nel caso specifico, vedi anche i commenti, abbiamo definito i comandi di
 151 compilazione da usare per il C e il Fortran, e i rispettivi flag, una variabile
 152 che contiene il pathname e la lista delle librerie del CERN e una variabile con una
 153 lista di file oggetto.
 154
 155 Per richiamare una variabile si usa la sintassi \texttt{\$(NOME)}, ad esempio
 156 nel makefile abbiamo usato:
 157 \begin{verbatim}
 158         $(FC) $(FFLAGS) -o riduzione riduzione.F readfile.o $(OBJ) $(LIBS)
 159 \end{verbatim}
 160 e questo significa che la regola verrà trattata come se avessimo scritto
 161 esplicitamente i valori delle variabili.
 162
 163 Veniamo ora alla parte principale del makefile che esegue la costruzione del
 164 programma:
 165 \begin{verbatim}
 166 riduzione: riduzione.F $(OBJ) commondef.f readfile.o
 167         $(FC) $(FFLAGS) -o riduzione riduzione.F readfile.o $(OBJ) $(LIBS)
 168 readfile.o: readfile.c
 169         $(CC) $(CFLAGS) -o readfile.o readfile.c
 170 $(OBJ): commondef.f
 171 \end{verbatim}
 172
 173 Il primo bersaglio del makefile, che definisce il bersaglio di default, è il
 174 programma di riduzione dei dati; esso dipende dal suo sorgente da tutti gli
 175 oggetti definiti dalla variabile \texttt{OBJ}, dal file di definizioni
 176 \texttt{commondef.f} e dalla routine C \texttt{readfile.o}; si noti il
 177 \texttt{.F} del sorgente, che significa che il file prima di essere compilato
 178 viene fatto passare attraverso il preprocessore C (cosa che non avviene per i
 179 \texttt{.f}) che permette di usare i comandi di compilazione condizionale del
 180 preprocessore C con la relativa sintassi. Sotto segue il comando di
 181 compilazione che sfrutta le variabili definite in precedenza per specificare
 182 quale compilatore e opzioni usare e specifica di nuovo gli oggetti e le
 183 librerie.
 184
 185 Il secondo bersaglio definisce le regole per la compilazione della routine
 186 in C; essa dipende solo dal suo sorgente. Si noti che per la compilazione
 187 vengono usate le variabili relative al compilatore C. Si noti anche che se
 188 questa regola viene usata, allora lo sarà anche la precedente, dato che
 189 \texttt{riduzione} dipende da \texttt{readfile.o}.
 190
 191 Il terzo bersaglio è apparentemente incomprensibile dato che vi compare
 192 solo il riferimento alla variabile \texttt{OBJ} con una sola dipendenza e
 193 nessuna regola, essa però mostra le possibilità (oltre che la
 194 complessità) di \texttt{make} connesse alla presenza di quelle regole
 195 implicite a cui avevamo accennato.
 196
 197 Anzitutto una una peculiarità di \texttt{make} è che si possono anche usare
 198 più bersagli per una stessa regola (nell'esempio quelli contenuti nella
 199 variabile \texttt{OBJ} che viene espansa in una lista); in questo caso la
 200 regola di costruzione sarà applicata a ciascuno che si potrà citare nella
 201 regola stessa facendo riferimento con la variabile automatica: \texttt{\$@}.
 202 L'esempio usato per la nostra costruzione però sembra non avere neanche la
 203 regola di costruzione.
 204
 205 Questa mancanza sia di regola che di dipendenze (ad esempio dai vari sorgenti)
 206 illustra le capacità di funzionamento automatico di \texttt{make}.
 207 Infatti è facile immaginarsi che un oggetto dipenda da un sorgente, e che
 208 per ottenere l'oggetto si debba compilare quest'ultimo.
 209
 210 Il comando \texttt{make} sa tutto questo per cui quando un bersaglio è un
 211 oggetto (cioè ha un nome tipo \texttt{qualcosa.o}) non è necessario
 212 specificare il sorgente, ma il programma lo va a cercare nella directory
 213 corrente (ma è possibile pure dirgli di cercarlo altrove, il caso è trattato
 214 nel manuale).  Nel caso specifico allora si è messo come dipendenza solo il
 215 file delle definizioni che viene incluso in ogni subroutine.
 216
 217 Inoltre come dicevamo in genere per costruire un oggetto si deve compilarne il
 218 sorgente; \texttt{make} sa anche questo e sulla base dell'estensione del
 219 sorgente trovato (che nel caso sarà un \texttt{qualcosa.f}) applica la regola
 220 implicita.  In questo caso la regola è quella di chiamare il compilatore
 221 fortran applicato al file oggetto e al relativo sorgente, questo viene fatto
 222 usando la variabile \texttt{FC} che è una delle variabili standard usata dalle
 223 regole implicite (come \texttt{CC} nel caso di file \texttt{.c}); per una
 224 maggiore flessibilità poi la regola standard usa anche la variabile
 225 \texttt{FFLAGS} per specificare, a scelta dell'utente che non ha che da
 226 definirla, quali flag di compilazione usare (nella documentazione sono
 227 riportate tutte le regole implicite e le relative variabili usate).
 228
 229 In questo modo è stato possibile usare una sola riga per indicare la serie di
 230 dipendenze e relative compilazioni delle singole subroutine; inoltre con l'uso
 231 della variabile \texttt{OBJ} l'aggiunta di una nuova eventuale routine
 232 \texttt{nuova.f} comporta solo l'aggiunta di \texttt{nuova.o} alla definizione
 233 di \texttt{OBJ}.
 234
 235
 236 \section{Cuncurrent Version System -- CVS}
 237
 238 Il programma CVS è un sistema di archiviazione dei programmi che consente di
 239 tenere traccia di tutte le modifiche e di condividere un archivio comune per
 240 progetti portati avanti da diverse persone.
 241
 242 \subsection{Introduzione}
 243 CVS è basato sul concetto di repositorio, un archivio in cui vengono riposti
 244 e da cui vengono presi i sorgenti dei programmi. L'archivio tiene traccia delle
 245 diverse versioni registrate; i programmatori inviano le modifiche usando una
 246 copia locale che hanno nella loro directory di lavoro.
 247
 248 CVS può gestire più di un progetto, esso organizza i progetti in
 249 \textsl{moduli} identificati dal nome della directory in cui sono messi i file
 250 relativi, ad esempio:
 251 \small
 252 \begin{verbatim}
 253 [piccardi@pcpamela ~]$ ls /usr/local/cvsroot/
 254 CVSROOT  adidsp  geometry  muonacq  pamela
 255 \end{verbatim}
 256 \normalsize %$
 257 in questo caso si hanno i moduli \texttt{adidsp geometry muonacq pamela}; un
 258 utente potrà recuperare tutti i file relativi al modulo \texttt{pamela} che
 259 andaranno nella directory \texttt{pamela}; è anche possibile gestire una
 260 gerarchia di moduli, inseriti in un albero di directory.
 261
 262 CVS ha una directory base dove tiene gli archivi (che nel è appunto
 263 \texttt{/usr/local/cvsroot}) e i vari file amministrativi; ogni progetto deve
 264 fare riferimento ad essa; in un progetto attivo essa viene memorizzata nei
 265 file amministrativi locali del progetto (ad esempio per un utente che ha il
 266 progetto \texttt{muonacq} nella sua home directory sarà in
 267 \texttt{\tild/muonacq/CVS}) e non è necessario specificarla; in generale essa
 268 viene tenuta dalla variabile di shell \texttt{CVSROOT} (inizializzata allo
 269 startup), o specificata direttamente dall'utente con l'apposita opzione
 270 \texttt{-d} (ex. \texttt{cvs -d /usr/local/cvsroot comando opzioni}).
 271
 272 Normalmente l'archivio si tiene su una macchina remota e vi si accede via
 273 rete. Per repositori esterni esistono varie modalità di accesso, la via più
 274 semplice è quella dell'uso di \texttt{ssh} come rimpiazzo di \texttt{rsh} per
 275 l'accesso esterno; in tal caso la directory del repositorio si può accedere
 276 con la sintassi: \small
 277 \begin{verbatim}
 278 cvs -d :ext:utente@server:/usr/local/cvsroot comando
 279 \end{verbatim}
 280 \normalsize
 281
 282 questo però comporta che sulla macchina remota \texttt{server} sia installato
 283 il server \texttt{ssh} ed esista l'utente \texttt{utente} con privilegi di
 284 accesso ai file; inoltre sulla macchina ospite deve esser stata definita la
 285 variabile di shell \texttt{CVS\_RSH=ssh}.
 286
 287 In questo modo ssh si collega alla macchina remota ed esegue il comando CVS con
 288 una connessione criptata dopo aver richiesto la password di \texttt{utente}.
 289
 290
 291 \subsection{Utilizzo di \texttt{cvs}}
 292
 293 Per creare un repositorio a partire da un gruppo di programmi esistente basta
 294 dare il comando \texttt{cvs import project tag release} nella directory dei
 295 sorgenti; verrà creato nel repositorio il modulo di nome \texttt{project} a
 296 cui poi si potrà accedere con i successivi comandi; \texttt{tag} è una
 297 etichetta di versione iniziale (ex. \texttt{1.1.1}) dato a tutto il blocco e
 298 \texttt{release} una etichetta di versione data ai programmi.
 299
 300 Una volta creato il repositorio è d'uopo cancellare la directory e ripartire
 301 dal progetto appena creato. Per recuperare ex-novo tutti i file di un progetto
 302 il comando da dare è:
 303 \small
 304 \begin{verbatim}
 305 cvs [-d ...] checkout project [-r rel] [-D date]
 306 \end{verbatim}
 307 \normalsize che creerà la directory \texttt{project} nella directory corrente
 308 con l'ultima versione dei file archiviata; se non si vuole la versione più
 309 aggiornata, ma una versione precedente si può usare l'opzione \texttt{-r} che
 310 scaricherà la versione identificata dall'etichetta specificata (vedi la parte
 311 seguente sul comando \texttt{tag}) o l'opzione \texttt{-D} che scaricherà la
 312 versione più recente prima della data specificata.
 313
 314 Una volta scaricato il progetto è possibile evitare di specificare la
 315 directory base del repositorio con l'opzione \texttt{-d} qualora i comandi
 316 vengano dati all'interno della directory creata, essa viene tenuta nel file
 317 \texttt{CVS/Root}, e può essere cambiata (qualora si usino più repositori)
 318 editando detto file.
 319
 320 Una volta creata la propria copia locale dei programmi, è possibile lavorare
 321 su di essi stando nella relativa directory,
 322 e apportare tutte le modifiche che si vogliono; due comandi
 323 permettono di schedulare la rimozione o l'aggiunta di file al repositorio:
 324 \small
 325 \begin{verbatim}
 326 cvs add file1.c
 327 cvs remove file2.c
 328 \end{verbatim}
 329 \normalsize
 330 ma niente viene modificato nel repositorio fintanto che non viene dato il
 331 comando \texttt{commit}:
 332 \small
 333 \begin{verbatim}
 334 cvs commit [file]
 335 \end{verbatim}
 336 (è possibile mandare le modifiche anche per il singolo file).
 337
 338 Questi comandi comunque non effettuano le modifiche se i file del repositorio
 339 nel frattempo sono stati modificati; in questo caso rilevano le differenze e
 340 restituiscono un \textit{merging} delle versioni locale/globale nella
 341 directory di lavoro, che è compito del programmatore esaminare per eliminare
 342 eventuali contrasti.
 343
 344 Per esempio viene eseguito un commit su una versione già modificata da un
 345 altro sul repositorio, il programma segnalerà che c'è un conflitto e
 346 chiederà al ``committente'' di intervenire sui file per i quali sono stati
 347 rilevati i conflitti .
 348
 349 Le sezioni di codice in conflitto sono separate come:
 350 \begin{verbatim}
 351 <<<<<<< Makefile
 352         $(CC) $(CFLAGS) -o pamacq pamacq.c -lm
 353 =======
 354         $(CC) $(CFLAGS) -o pamacq pamacq.c
 355
 356 >>>>>>> 1.22
 357 \end{verbatim}
 358 nel caso si c'è stata una modifica sul file (mostrata nella parte superiore)
 359 incompatibile con quella fatta nel repositorio (mostrata nella parte
 360 inferiore). Prima di eseguire un \textit{commit} occorre pertanto integrare le
 361 modifiche e risalvare il file; a questo punto il \textit{commit} diventa
 362 possibile.
 363
 364 \subsection{I principali sotto comandi}
 365
 366 I principali sottocomandi di \texttt{cvs} utilizzati per controllare lo stato
 367 dei sorgenti sono:
 368
 369 \begin{itemize}
 370 \item \texttt{cvs update} \\
 371   scarica le eventuali modifiche dei file del repositorio e le applica ai file
 372   nella directory corrente. In caso di conflitti con modifiche locali effettua
 373   un \textit{merging} con le caratteristiche esposte in precedenza.
 374
 375 \item \texttt{cvs status} \\
 376   compara i file nella directory locale con quelli del repositorio e stampa a
 377   schermo le informazioni di stato di ciascuno di essi:
 378 \begin{itemize}
 379 \item \texttt{Locally Modified} il file è stato modificato localmente
 380 \item \texttt{Locally Added} il file è stato aggiunto localmente
 381 \item \texttt{Up to date} il file è identico
 382 \item \texttt{Needs Patch} il file è cambiato sul repositorio (va aggiornato)
 383 \item \texttt{Needs Merge} il file è cambiato sul repositorio e localmente, le
 384   differenze vanno riunite prima del commit, in genere basta un \texttt{cvs
 385     update}, ma in caso di conflitti questi vanno sanati.
 386
 387 \end{itemize}
 388
 389 \item \texttt{cvs log} \\
 390   legge il giornale del modulo corrente; in questo modo si hanno le
 391   informazioni sullo stato del progetto all'interno del repositorio, per
 392   ciascun file è vengono mostrati informazioni generali su:
 393 \begin{itemize}
 394 \item release attuale
 395 \item presenza di eventuali ramificazioni
 396 \item lista di etichette simboliche
 397 \item i messaggi di commento salvati ad ogni \textit{commit}
 398 \end{itemize}
 399
 400 \item \texttt{cvs rtag Etichetta modulo} \\
 401   permette di associare una etichetta alla corrente versione dei file nel
 402   progetto così come sono nel repositorio; in modo da poter ritornare a quello
 403   stato del software con il comando \texttt{cvs checkout -rEtichetta module}.
 404
 405 \end{itemize}
 406
 407 %TODO mettere SVN al posto di CVS
 408
 409
 410 % LocalWords:  make Makefile makefile shell FC FLAGS CFLAGS pathname CERN
 411 % LocalWords:  OBJ commondef readfile FFLAGS Cuncurrent Version System CVS home
 412 % LocalWords:  adidsp geometry muonacq andaranno CVSROOT startup cvs ssh rsh to
 413 % LocalWords:  project tag Root commit update merging Locally Modified Added
 414 % LocalWords:  Needs Patch Merge log rtag checkout module
 415
 416
 417
 418 %%% Local Variables:
 419 %%% mode: latex
 420 %%% TeX-master: "gapil"
 421 %%% End: