Narzędzia programistyczne

Narzędzia

programistyczne

Tomasz Borzyszkowski

Biblioteki statyczne

2

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

Biblioteki dzielone

3

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

4

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:

5

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

6

main.c

1.c

2.c

_3.c

a.h

_b.h

c.h

7

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}

8

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,

9

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.

10

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

11

RCS przykład użycia

cd

Podsumowanie zmian:

rlog istotny.c

Powrót do wcześniejszej wersji pliku: co -r1.1 istotny.c Różnice między wersjami:

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

12

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.

CVS

13

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

14

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

15

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 .

16

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)

17

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:

18

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:

19

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

 $Name$ rozwinięcie do nazwy znacznika użytego przy jego

pobieraniu

 $Revision$ rozwinięcie do numeru korekty

System CVS automatycznie aktualizuje słowa kluczowe po każdym pobraniu.

20

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ę:

21

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.1 1.2 1.3 1.4 1.5 1.6

Wydanie 1 Wydanie 2

1.2.1 1.2.2

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

22

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

23

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

24

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

25

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

26

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ą: