CVS

Narzędzia
programistyczne
Tomasz Borzyszkowski
Biblioteki statyczne
W Linuxie istnieją dwa rodzaje bibliotek: statyczne i dzielone.
Statyczne dołączane są do kodu programu w czasie linkowania,
dzięki czemu plik wynikowy jest większy o dołączony kod. Biblioteki
te są zbiorem plików obiektowych (*.o), utworzonych przez program
ar:
ar rcs nazwa_bib.a plik1.o plik2.o ...
gdzie:
r włącza do biblioteki plik obiektowy, zastępując inne pliki
obiektowe o takiej samej nazwie znajdujące się w archiwum
c tworzy bibliotekę, nie podając żadnych komunikatów, jeśli nie
istnieje
s uaktualnia tablicę odwzorowującą nazwy symboli na nazwy
plików obiektowych
patrz lib[12].{c,h}, prog_lib.c oraz stat1.sh
2
Biblioteki dzielone
Pozwalają na czytanie zawartości biblioteki w czasie wykonywania.
Cechy pozytywne:
 współdzielenie kodu przez wszystkie procesy korzystające z
biblioteki dzielonej, więc jeżeli więcej niż jeden program korzysta
z tego samego kodu, to lepiej umieścić go w bibliotece dzielonej
 Biblioteki dzielone oszczędzają pamięć systemu, dzięki czemu
system działa szybciej
 kod biblioteki dzielonej nie jest kopiowany do pliku
wykonywalnego, a zatem tylko kopia kodu znajduje się na dysku,
oszczędza to miejsce na dysku i czas potrzebny na kopiowanie
 jeżeli w bibliotece dzielonej znajdzie się błąd, to można ją
zastąpić poprawioną wersją bez potrzeby powtórnej kompilacji
wszystkich programów, które z niej korzystają.
Cecha negatywna:
 złożoność programu; program składa się z wielu niezależnych
części i trzeba przenosić kod wynikowy wraz z bibliotekami
3
Biblioteki dzielone cd
Standardem kodowania w Linuxie jest to, że biblioteki zachowują
zgodność z poprzednimi wersjami. Program dziłający ze starą
biblioteką będzie także działać z nową biblioteką.
Nazwa wewnętrzna biblioteki składa się z nazwy biblioteki oraz
numeru wersji (np. libc.so.6). Jest to link symboliczny do pliku, w
którym biblioteka jest przechowywana (np. libc.so.6.1.3) .
Ścieżki do bibliotek systemowych są przechowywane w pliku /
etc/ld.so.conf. Dołączanie nowych katalogów bibliotek
systemowych wymaga dodania ich do pow. pliku i uruchomienia
programu ldconfig. Opcja -lnazwa_bib dołącza standardową
bibliotekę o nazwie libnazwa_bib.so, która jest utworzonym
przez ldconfig dowiązaniem do najnowszej wersji tej biblioteki
w systemie.
Tworzenie i korzystanie z bibliotek dzielonych:
Patrz lib[12].{c,h}, prog_lib.c oraz dziel[12345].sh
4
make wstęp
Progam make służy do zarządzania projektami informatycznymi
(sterowanie kompilacją kodu źródłowego, instalacja aplikacji oraz
przygotowanie stron podręcznika elektronocznego). make czyta plik
makefile, który opisuje wzajemne zależności między plikami
aplikacji.
Zależności definiują jak każdy plik końcowej aplikacji jest
powiązany z innymi plikami źródłowymi, np.:
mojaapl1: main.o 1.o 2.o 3.o
Reguły to akcje, które muszą zostać podjęte by zbudować dany
fragment aplikacji, np.:
mojaapl1: main.o 1.o 2.o 3.o
gcc -o mojaapl1 main.o 1.o 2.o 3.o
main.o: main.c a.h
gcc -c main.c
patrz Makiefile1
5
make przykład
main.c
1.c
2.c
3.c
a.h
b.h
c.h
6
make zaawansowane
W plikach makefile możemy używać makr. Makro definiujemy tak:
NAZWA_MAKRO=warto??
Natomiast rozwijamy makro tak:
$(NAZAWA_MAKRO) lub ${NAZWA_MAKRO}
Jeżeli nasza aplikacja wynikowa ma składać się z więcej niż z
jednego pliku, to możemy użyć specjalnego celu all. Graf
zależności jest wówczas sumą kilku drzew o różnych korzeniach.
Patrz Makiefile2
Możliwe jest także zedefiniowenie celów clean i install.
Wówczas komenda make clean, która zawsze kończy się
sukcesem, wykona swoją sekcję. Komenda make instal,
standardowo, najpierw tworzy aplikację, a następnie wykonuje
przypisany jej skrypt.
Patrz Makiefile3
7
make zaawansowane cd
Program make posiada reguły wbudowane. Pozwalają one
przeprowadzać kompilację pliku o ustalonej końcówce w sposób
domyślny (przegląd reguł wbudowanych make -p). Wypróbuj
komendę:
make hello
Możemy także zmieniać niektóre makrodefinicje:
make CC=gcc CFLAGS="-Wall -g" hello
gcc posiada reguły dla bibliotek statycznych, rozpoznaje je po .a
Patrz Makiefile4
W wersji GNU program make udostępnia opcję -jN umożliwiającą
realizację kompilacji przez N niezależnych procesów. Spróbuj:
make -f Makefile4 -j3
Opcja -MM kompilatora gcc tworzy listę zależności odp. dla make,
spróbuj:
gcc -MM main.c 1.c 2.c 3.c
8
RCS zarządzanie kodem źródłowym
RCS (Revision Control System) jest kolejnym narzędziem
wspomagającym zarządzanie kodem źródłowym. System ten składa
się z szeregu poleceń umożliwiających śledzenie zmian pliku
źródłowego i utrzymywanie pojedynczego pliku z listą zmian
zawierającą szczegóły zmian potrzebne do odtworzenia każdej
poprzedniej wersji pliku źródłowego.
Działanie RCS pokażemy na przykładzie prac nad programem
istotny.c
Inicjalizujemy program:
rcs -i istotny.c
wpisujemy komentarz:
To jest bardzo wa?ny plik demonstracyjny
Kończymy wpisując pojedynczą kropkę w wierszu lub znak końca
pliku. Powstał plik istotny.c,v.
9
RCS przykład użycia
Rejestujemy program:
ci istotny.c
Jeżeli wcześniej nie zainicjalizowaliśmy RCSa, to poprosi on o
podanie komentarza. Po rejestracji plik istotny.c został usunięty.
Chcemy teraz dokonać zmian w pliku istotny.c. W tym celu
musimy najpierw program wyrejestrować.
Wyrejestrowanie programu:
co -l istotny.c
Opcja -l powoduje zablokowanie pliku dla pozostałych
użytkowników jest to ważne przy projektach zespołowych. Do pliku
istotny.c dodajemy linię:
printf("To jest dodatkowa linia ....");
Następnie ponownie przy pomocy komendy ci istotny.c
rejestujemy zmiany i zapisujemy odpowiedni dla nich komentarz.
10
RCS przykład użycia
Podsumowanie zmian:
rlog istotny.c
Różnice między wersjami:
cd
Powrót do wcześniejszej wersji pliku:
co -r1.1 istotny.c
rcsdiff -r1.1 -r1.2 istotny.c
Identyfikowanie rewizji:
Wyrejestrowujemy program (co -l istotny.c), następnie przed
funkcją main() dodajemy linię:
static char *RCSinfo = "$Id$"
natomiast na jej końcu main() dodajemy:
printf("RCS Id pliku: \n%s\n", RCSInfo);
Rejestrujemy zmiany (ci istotny.c) podając odp. komentarz, a
następnie raz jeszcze wyrejestrowujemy. Jak zmienił się plik
istotny.c?
RCS posiada predefiniowany zestaw makr, które można używać
wewnątrz plików źródłowych. Najbardziej popularne są $Id$ - ciąg
identyfikujący rewizję oraz $RCSfile$ - nazwa pliku.
11
RCS przykład użycia
GNU i ident
Program make w wersji GNU posiada kilka wbudowanych reguł do
zarządzania pilkami RCS. Zobaczmy jak zadziałają następujące
komendy:
rm -f istotny.c
make istotny
make posiada regułę tworzenia pliku bez rozszerzenia z pliku w
rozszerzeniem .c, używając cc, oraz reguły tworzenia pliku z
rozszerzeniem .c z pliku .c,v wykorzystując RCS. Po kompilacji
pliku .c jest on usuwany.
Polecenie ident (wypróbuj): ident istotny
ident pobrał z pliku wykonywalnego ciąg $Id$. Jest on ważnym
narzędziem do sprawdzania, w której wersji programu klient zgłosił
błąd.
Istnieją także inne systemy kontroli kodu źródłowego np.
komercyjny SCCS. Posiada on podobne funkcje co RCS i jest
określony w standardzie X/Open.
12
CVS
wstęp
Nowszym i nowocześniejszym narzędziem od RCSa do zarządzania
kodem źródłowym jest CVS (Concurrent Version System). CVS
powstał w 1986 roku jako zestaw kilku skryptów powłoki. Obecny
system opiera się na pracy Briana Berlinera rozpoczętej w 1989
roku.
CVS zastępuje powoli RCS w pracach zespołów programistów,
ponieważ:
 CVS można łatwo przystosować go do pracy w sieci, także przez
Internet
 CVS umożliwia jednoczesną pracę wielu programistów nad tym
samym kodem źródłowym i w wielu wypadkach pozwala na
automatyczne dołączanie zmian wprowadzanych do projektu przez
różnych programistów
 CVS ma znacznie lepiej działający system zarządzania zbiorami
plików niż RCS
13
CVS
terminologia
Przed rozpoczęciem prac z CVSem musimy zapoznać się z
niezbędną terminologią:
 Pobranie (Check Out) pobranie kopii jednego lub wielu plików z
głównego źródła z zamiarem wprowadzenia zmian
 Zatwierdzenie (Commit) wprowadzenie zmian dokonanych lokalnie
w pliku źródłowym do głównej kopii tego pliku
 Projekt (Project) zbiór plików wchodzących w skład aplikacji
 Repozytorium (Repository) miejsce przechowywania głównej kopii
kodu źródłowego w systemie CVS
 Korekta (Revision) każda zmiana w pliku źródłowym to korekta;
zgodnie ze specyfikacją CVS jest to oznakowana zmiana w
pojedynczym pliku źródłowym
14
CVS
repozytorium
Przed uruchomieniem CVS należy utworzyć repozytorium, które
posłuży do przechowywania głównych kopii plików źródłowych oraz
wewnętrznych plików konfiguracyjnych. Aby utworzyć
repozytorium należy:
 Utworzyć grupę użytkownikow repozytorium, np.:
# groupadd cvs-users
 Utworzyć katalog repozytorium, np.:
# mkdir /usr/local/cvsrep
 Utworzyć pliki do zarządzania repozytorium:
# cvs -d /usr/local/cvsrep init
 Nadać prawa do repozytorium dla grupy cvs-users:
# cd /usr/local/cvsrep
# chmod g+w .
# chgrp -R cvs-user .
15
CVS
nowy projekt
Przed rozpoczęcięm pracy dobrze jest ustawić zmienne
środowiskowe, oto niektóre z nich:
 CVSROOT ścieżka do repozytorium
 CVSEDIT komenda wywołująca edytor
 CVSIGNORE lista wzorców nazw plików, które mają być ignorowane
podczas wykonywania poleceń CVS
W katalogu cvs-app znajduje się przykładowa aplikacja. Dodajemy
wszystkie pliki do repozytorium:
$ cvs import Opr1App tomek start
Literki pojawiające się przed nazwami plików znaczają:
C konflikt (plik już istnieje);
I zignorowany;
L dowiązanie (CVS nie obsługuje dowiązań);
M zmodyfikowany;
R usunięty;
N nowy;
U zaktualizowany;
? zapytanie (znaleziono niewystępujący w repozytorium plik
lokalny, nieoznaczony jako ignorowany)
16
CVS
praca
Praca nad projektem kontrolowanym przez CVS polega na:
 Pobieraniu plików z repozytorium przed nanoszeniem zmian; po
pobraniu plików powstanie katalog CVS, jest to katalog roboczy
systemu CVS i nie wolno w nim niczego zmieniać:
$ cvs checkout Opr1App
 Porównanie zmian dokonanych w kopiach lokalnych z
repozytorium; ignorowane jest porównywanie plików lokalnych,
które nie są umieszczone w repozytorium (-B ignoruje puste
wiersze): $ cvs diff -B
Jeżeli wprowadzone przez nas zmiany nie są satysfakcjonujące,
należy usunąć plik lokalny, a następnie wykonać polecenie:
$ cvs update
 Akceptowanie zmian dokonanych w kopiach lokalnych i
aktualizacja repozytorium:
$ cvs commit
17
CVS
praca cd
 Zwalnianie projektu, gdy wstrzymujemy pracę nad projektem
należy go zwolnić, tj. poinformować CVS, że w danej chwili nad
nim nie pracujemy; przechodząc o katalog wyżej wykonujemy
komendę: $ cvs release
 Przeglądanie zmian:
$ cvs log nazwa_pliku
 Dodawanie plików do repozytorium, plik zostanie faktycznie
dodany dopiero po zatwierdzeniu zmian najbliższą komendą cvs
commit:
$ cvs add nazwa_pliku
 Usuwanie plików z repozytorium, plik zostanie faktycznie
usunięty dopiero po zatwierdzeniu zmian najbliższą komendą cvs
commit:
$ cvs remove nazwa_pliku
18
CVS
słowa kluczowe
CVS posiada, podobnie jak RCS, możliwość rozwijania słów
kluczowych. Dostępne są następujące słowa kluczowe:
 $Author$ rozwinięcie do systemowej nazwy użytkownika
będącego autorem pliku
 $Date$
rozwinięcie do daty ostatniego zatwierdzenia
 $Headers$ rozwinięcie do niektórych informacji nagłówkowych
 $Id$
rozwinięcie do informacji standardowych, bez ścieżek
 $Log$
rozwinięcie do cvs log danego pliku
rozwinięcie do nazwy znacznika użytego przy jego
pobieraniu
 $Revision$ rozwinięcie do numeru korekty
 $Name$
System CVS automatycznie aktualizuje słowa kluczowe po każdym
pobraniu.
19
CVS
znaczniki
Jeżeli wydajemy projekt składający się z wielu plików, to
zazwyczaj każdy plik ma korekty o innych numerach. Bardzo ważna
jest możliwość utworzenia tzw. wydania wersji, składającego się z
wielu plików o różnych numerach rewizji.
W wydawaniu wersji może nam pomóc stosowanie znaczników.
Znaczniki, to nazwy odnoszące się do całego zestawu plików
składających się w danej chwili na aktualną wersję projektu,
niezależnie od faktycznych numerów korekty tych plików.
Do nadawania znaczników służy komenda:
$ cvs tag nazwa_znacznika
Wypróbuj komendę:
$ cvs -d /?cie?ka tag -c pierwsze-wydanie
Wypróbuj komendę:
$ cvs -d /?cie?ka tag -h main.c
20
CVS
rozgałęzienia projektu
Czasami istnieje konieczność podziału projektu na dwie lub więcej
wersji, które będą rozwijane niezależnie. W CVS sposobem na to
jest rozgałęzianie, pozwalające na niezależną pracę ze starymi i
nowymi wersjami.
1.2.1 1.2.2
Wydanie 1
Wydanie 2
1.2
1.3
1.4 1.5
1.6
1.1
By utworzyć rozgałęzienie należy wykonać komendę:
$ cvs tag -b nazwa_rozga??zienia
Następnie zwalniamy projekt i pobieramy rozgałęziony projekt:
$ cvs release
$ cvs checkout -r nazwa_rozga??zienia
21
Dokumentacja rodzaje
W systemie Linux istnieje wiele sposobów uzyskania pomocy. Oto
niektóre z nich:
 Opcje wiersza poleceń, informacje o dostępnych opcjach danej
komendy możemy uzyskać uruchamiając ją z opcją --help. Np.:
$ cp --help
 Podręcznik systemowy, zawiera więcej szczegółowych
informacji. Dostęp do stron podręcznika za pomocą komendy man.
Np.:
$ man cp
 Dokumentacja kodu programu, zawiera szczegółowy opis źródeł
programu. Programista nie przygotowuje tradycyjnego kodu
programu, a raczej tekst zawierający części kodowe i części
dokumentacyjne. Do wydzielania dokumnetacji i kodu z takiego
tekstu służą takie programy jak: noweb i cweb
22
Podręcznik elektr. sekcje
Podręcznik elektroniczny został stworzony dla zróżnicowanych
programów, od prostych poleceń linii komend, do funkcji bibliotek
standardowych. Aby pomóc użytkownikowi w znajdowaniu
informacji podzielono podręcznik na następujące sekcje:
1.Programy lub polecenia dostępne dla wszystkich użytkowników
2.Wywołania systemowe (funkcje obsugiwane przez jądro)
3.Funkcje biblioteczne (zawarte w bibliotekach systemowych)
4.Pliki specjalne (zwykle umieszczone w katalogu /dev)
5.Formaty plików i konwencje nazewnicze, np. /etc/passwd
6.Gry
7.Ogólne konwencje i pakiety makropoleceń
8.Polecenia administracyjne
9.Niestandardowe funkcje jądra
Spróbuj: $ man echo
$ man 3 echo
$ man 4 tty
$ man sh-utils
23
Podręcznik elektr. elementy
 NAME, jedyny obowiązkowy element strony, zawiera nazwę












opiswanego programu i jego krótki opis
SYNOPSIS, skrótowy opis interfejsu programu lub funkcji
DESCRIPTION, pełen opis programu lub funkcji
REURN VALUES, wartości zwracane przez funkcję lub program
EXIT STATUS, kody powrotu programu lub funkcji
OPTIONS, opcje programu lub argumenty funkcji
FILES, pliki używane przez program lub funkcję
ENVIRONMENT, zmienne systemowe mające wpływ na działanie
DIAGNOSTICS, opis komunikatów o błędach i ostrzeżeń
SECURITY, lista możliwych zagrożeń wnoszonych przez program
do systemu
BUGS, opis znanych błędów
AUTHOR, osoby uczestniczące w tworzeniu programu
SEE ALSO, lista stron podręcznika o podobnej tematyce
24
Podręcznik elektr. tworzenie
Najprostszą metodą rozpoczęcia pracy nad nową stroną będzie
skopiowanie i modyfikacja już istniejącej. Opis języka poleceń
podręcznika można uzystać pisząc:
$ man 7 man
Pisząc podręcznik elektroniczny należy przestrzegać kilku prostych
reguł:
 Polecenia lub makropolecenia programu troff składają się z kropki
i następujących za nią dwóch liter. Wielkość liter ma znaczenie.
 Polecenia występują zazwyczaj w oddzielnych wierszach, w których
podawane są także argumenty tych poleceń (jeśli są wymagane)
 Istnieje kilka poleceń używanych wewnatrz wierszy, rozpoczynają
się od znaku “\”
 Znaki specjalne są poprzedzone “\*”
 W tekście strony można stosować komentarze rozpoczynając linię
znakiem \” , komentarz do końca linii
Patrz: mojaappl.man
25
Podręcznik elektr. tworzenie cd
W większości systemów Linuxowych strony podręcznika są
formatowane poleceniem groff (GNU-odpowiednik UNIXowego
nroff).
Formatowanie strony, komendą:
$ groff -Tascii -man mojaapl.man
Aby strony były dostępne dla użytkowników, wynik formatowania
należy umieścić w katalogu /usr/man/man1. Polecenie man używa
zmiennej środowiskowej MANPATH.
Zobacz także /etc/man.config.
Wersję poscriptową strony podręcznika można uzyskać komendą:
$ groff -Tps -man mojaapl.man > mojaapl.ps
26