Oprogramowanie i wykorzystanie stacji roboczych Wykład 1 Plan

Plan wykładów
Wybrane narz˛edzia wspomagajace
˛ proces tworzenia
oprogramowania
Oprogramowanie i wykorzystanie
stacji roboczych
Podstawy systemu X Window
Biblioteka Qt
Tworzenie grafiki trójwymiarowej na przykładzie blioteki OpenGL
Wykład 1
Programowanie wielowatkowe
˛
Poprawa wydajności oprogramowania
Dr inż. Tomasz Olas
[email protected]
Instytut Informatyki Teoretycznej i Stosowanej
Politechnika Cz˛estochowska
Wykład 1
Wykład 1 – p. 1/24
Konkurs programistyczny
Literatura
N. Matthew, R. Stones: Zaawansowane programowanie w systemie
Linux, Helion, 2002.
D. Solin: Poznaj programowanie przy u|yciu biblioteki Qt w 24
godziny, Infoland, 2001
www.trolltech.com.
J. D. Folley i inni: Wprowadzenie do grafiki komputerowej, WNT.
R. S. Wright jr, M. Sweet: OpenGL ksiega
˛
ekperta. Helion, 1999
P. Andrzejewski, J. Kurzak: Wprowadzenie do OpenGL, Kwantum
2000.
Witryna internetowa projektu OpenGL: www.opengl.org.
B. Lewis, D. J. Berg: Multithreaded Programming with Pthreads, Sun
Microsystems Press, 1998.
B. Nichols, D. Buttlar: Pthreads Programming, O’Reilly„ 1996.
Adres strony www konkursu: www.power.com.pl/pl/konkurs
Wykład 1 – p. 3/24
Wykład 1
Konstrukcja wielomodułowa programów
Zapewnia logiczna˛ strukture˛ i poprawia czytelność programu.
Niezależne moduły moga˛ być oddzielnie testowane i po kompilacji
wykorzystywane w różnych programach.
Make
Make jest narz˛edziem automatycznie określajacym,
˛
które fragmenty
kodu wymagaja˛ ponownej kompilacji i wykonuje ich kompilacje.
˛
Umożliwia wykorzystywanie w programie w jezyku
˛
C/C++ procedur
napisanych w innych jezykach
˛
programowania.
Plik makefile (Makefile) - opisuje relacje pomiedzy
˛
plikami w
projekcie oraz polecenia służace
˛ do uaktualniania poszczególnych
plików.
Zwieksza
˛
szybkość kompilacji w trakcie modyfikowania programu.
wywołanie:
make
make -f makefile_name
make nazwa_reguly
Reguły, dyrektywy i definicje makr powinny rozpoczynać sie˛ w
pierwszej kolumnie tekstu, natomiast polecenia musza˛ być
poprzedzone co najmniej jednym znakiem pustym.
Wykład 1
Wykład 1 – p. 5/24
Make - reguły
Make - makrodefinicje
Można rozróżnić dwa rodzaje reguł:
Definiowanie makrodefinicji:
Reguły jawne:
nazwa_makrodefinicji=tekst_rozwini˛
ecia
zbiór_uakt [zbiór_uakt [...]]: {{ścieżki}][zbiór-uzal ...]
polecenie
przykład:
PROGRAM=bierki
OBJS=foo.c
przykład:
Rozwijanie makrodeficji:
foo.o : foo.c defs.h
gcc -c -g foo.c
$(nazwa_makrodefinicji)
Reguły niejawne:
przykład:
[katalog_źródł].rozsz_źródł[katalog_docelowy].rozsz_docelowe:
polecenie
$(PROGRAM): $(OBJS)
g++ -c $(OBJS) -o $(PROGRAM)
przykład:
.c.o:
gcc -c $<
Wykład 1 – p. 7/24
Wykład 1
Make - przykład
Make - makrodefinicje predefiniowane
$* - Makro to rozwija sie˛ w nazw˛e zbioru uzależniajacego
˛
(ze
ścieżka˛ dostepu,
˛
lecz bez rozszerzenia).
$< - Makro to działa tak jak $*, z ta˛ różnica,˛ że uzyskana nazwa
zbioru zawiera rozszerzenie.
$@ - Makro to rozwija sie˛ w nazw˛e zbioru uzależnianego (wraz z jego
rozszerzeniem).
PROJECT = bierki
INC
=
./include
INSTALLBIN = $(HOME)/opt/bin
CXX = g++-2.95
CXXFLAGS += -I$(INC)
OBJS = $(PROJECT).o okno.o
all: $(PROJECT)
$: - Ta makrodefinicja rozwija sie˛ w ścieżk˛e dostepu
˛
do zbioru, ale
bez jego nazwy. Jeśli wystepuje
˛
w regułach jawnych, to uzyskana
zostanie ścieżka zbioru docelowego, w niejawnych zaś ścieżka
zbioru przetwarzanego.
%.o: %.cpp
$(CXX) $(CXXFLAGS) -c -o $@ $<
$(PROJECT): $(OBJS)
$(CXX) $(LDFLAGS) -o $@ $(OBJS) $(LIBS)
clean:
-rm -rf *.o
realclean: clean
-rm -rf $(PROJECT)
Wykład 1
Wykład 1 – p. 9/24
Make - reguły standardowe
Make - automatyczne generowanie zależności
Kompilator gcc posiada opcje -M, -MM, które generuja˛ zależności od
plików nagłówkowych dla przetwarzanego pliku źródłowego.
Istnieje zbiór reguł, których stosowanie powoduje, że pliki makefile sa˛
znacznie prostsze do zrozumienia i stosowania:
Przykład:
all
depend:
$(CXX) -MM $(CXXFLAGS) *.cpp > depend.mk
test
clean
...
dist
include depend.mk
distclean
Przykładowe wygenerowane zależności:
realclean
domain.o: src/domain.cpp include/domain.h include/fxdrstream.h \
include/except.h
fxdrstream.o: src/fxdrstream.cpp include/fxdrstream.h
mpi_wrapper.o: src/mpi_wrapper.cpp include/mpi_wrapper.h
install
uninstal
Wykład 1 – p. 11/24
Wykład 1
Narzedzia
˛
wspierajace
˛ program make
makedepend - służy do automatycznego generowania zależności
pomiedzy
˛
plikami w projekcie. Dostarczany razem z systemem X
Window.
Imake - służy do mechanicznego generowania plików makefile dla
systemu X. Opiera sie˛ na wywołaniu programu makedepend
autoconf - generuje skrypt powłoki configure dopasowany do
projektu.
automake - narz˛edzie podobny do autoconf - umożliwia
generowanie plików makefile, posiadajacy
˛ jednak wbudowane
mechanizmy badania zależności (podobna˛ do programu Imake).
tmake - narz˛edzie firmy TrollTech pierwotnie utworzone dla biblioteki
Qt, ale może być wykorzystywane również w innych projektach.
GNU Autoconf (I)
Autoconf jest narz˛edziem (zestawem makr M4) służacym
˛
do
generownia skryptów powłoki, które pozwalaja˛ na automatyczne
dostosowanie pakietów oprogramowania (w postaci kodu
źródłowego) do specyfiki wielu różnych systemów operacyjnych.
Wygenerowane skrypt konfiguracyjny (configure) jest niezależny
od narz˛edzia Autoconf i podczas kompilacji pakietu nie jest ono
wymagane.
Skrypt configure wykonuje szereg testów majacych
˛
na celu
sprawdzenie, czy i ewentualnie gdzie w systemie znajduja˛ sie˛
narz˛edzia, biblioteki, pliki nagłówkowe niezbedne
˛
do poprawnego
utworzenia programu. Po określeniu środowiska w którym
kompilowany jest program skrypt ten powinien wygenerować
odpowiednie definicje i opcje kompilacji.
Cz˛esto narz˛edzie Autoconf jest stosowany w połaczeniu
˛
z
programami Automake i Autoheader.
Wykład 1
Wykład 1 – p. 13/24
Tworzenie skryptu configure
GNU Autoconf (II)
Szczególnie ważna˛ kwestia˛ przy tworzeniu plików wejściowych dla
programu Autoconf jest określenie, co należy sprawdzać przy
kompilacji programu na różnych platformach systemowych.
W celu wygenerowania skryptu configure należy utworzyć plik
konfiguracyjny dla programu Autoconf: configure.ac (lub
configure.in).
Plik konfiguracyjny tworzy sie˛ w oparciu o makra sprawdzajace:
˛
Przykładowa struktura pliku configure.ac:
Autoconf zawiera zbiór makr sprawdzajacych
˛
dla teypowych
elementów,
w przypadku braku gotowego testu dla danego elementu (pliku
nagłówkowego, bibilioteki, funkcji) można wykorzystać test
ogólny (np. na obecność pliku w systemie plików),
w ostateczności należy utworzyć fragment testujacy
˛ w jezyku
˛
Bourne shella.
Uworzenie pliku configure nastapi
˛ po uruchomieniu programu
autoconf.
Wykład 1 – p. 15/24
Wykład 1
Autoconf - przykład (I)
Autoconf - przykład (II)
AC_INIT(sample,0.1)
AC_PROG_CXX
# Checks for performing tests
CPPUNIT="no"
AC_ARG_ENABLE(test, [--enable-test enable test suite [default=yes]],
,enable_test="yes")
if test ! "x$enable_test" = "xno"; then
AC_PATH_PROG(CPPUNIT_CONFIG,cppunit-config,no)
if test "x$CPPUNIT_CONFIG" = "xno"; then
AC_MSG_ERROR([cppunit is needed but not found.])
fi
CPPUNIT="yes"
CPPUNIT_CFLAGS=‘$CPPUNIT_CONFIG --cflags‘
CPPUNIT_LIBS=‘$CPPUNIT_CONFIG --libs‘
AC_SUBST(CPPUNIT_CFLAGS)
AC_SUBST(CPPUNIT_LIBS)
fi
AC_SUBST(CPPUNIT)
AC_CONFIG_FILES(Makefile)
AC_OUTPUT
Plik Makefile.in:
...
# CppUnit flags
ifeq ($(CPPUNIT), yes)
CXXFLAGS += @CPPUNIT_CFLAGS@
LDFLAGS += @CPPUNIT_LIBS@
endif
$(OBJ)/%.o: $(SRC)/%.cpp
$(CXX) -c $(CXXFLAGS) -o $@ $<
$(PROGRAM): $(OBJS)
$(CXX) -o $(PROGRAM) $(LDFLAGS) $(OBJ)
Wykład 1 – p. 17/24
Wykład 1
Jam
Jam kontra Make
Jednym z ciekawszych projektów, które w przyszłości moga˛ zastapić
˛
program make jest Jam.
Zalety:
Plik konfiguracyjny dla programu Make:
progam: data.o main.o io.o
gcc data.o main.o io.o -o progam
Zwiekszenie
˛
projektu nie prowadzi do tak drastycznego zwiekszania
˛
sie˛ pliku
data.o: data.c
gcc -c data.c
konfiguracyjnego jak ma to miejsce w przypadku programu make.
Automatycznie generowane sa˛ zależności od plików nagłówkowych.
Jam buduje duże projekty rozmieszczone w wielu katalogach za jednym podejściem,
bez rekursywnego nawracania jak to robi make, śledzac
˛ wszystkie pliki jednocześnie.
main.o: main.c
gcc -c main.c
Może pracować na wielu procesorach.
Jam jest mały (np. 92 kB), praktycznie nie obciaża
˛ procesora, i nie tworzy dodatkowych
plików (jak np. nmake, SunOS make).
io.o: io.c
gcc -c io.c
Może być dowolnie konfigurowany poprzez tzw. reguły (Jamrules).
io.o: io.h
main.o: io.h data.h
data.o: data.h io.h
Plik konfiguracyjny dla programu Jam:
Main progam : data.c main.c io.c ;
Wykład 1 – p. 19/24
Wykład 1
Apache Ant (I)
Apache Ant (II)
Apache Ant jest cz˛eścia˛ projektu Apache Jakarta.
Opiera sie˛ na podobnym założeniu co make jeżeli chodzi o
zależności i reguły, ale nie zakłada że sa˛ to pliki i że głównym celem
reguł jest uaktualnienie zadań.
Używa jezyka
˛
XML.
Jest w pełni niezależny od platformy.
Został napisany z myśla˛ o Javie, ale posiada również wsparcie do
tworzenia projektu w innych jezykach
˛
programowania (również w
C++).
Plik konfiguracyjny dla programu Ant jest plikiem w formacie XML.
Zazwyczaj nosi nazw˛e build.xml.
Składa sie˛ on z różnej ilości różnych tagów, zwanych <target> (cel).
Może to być np. kompilacja, utworzenie archiwum, utworzenie
dokumentacji czy też wysłanie poczty elektronicznej.
Każdy cel składa sie˛ z dowolnej ilości wykonywanych zadań <task>.
Jest to prosta czynność, która bedzie
˛
wykonywana, np. tworzenie
katalogu, kopiowanie pliku, kompilacja kodu źródłowego. Każde
zadanie może posiadać parametry i być zależne od innych zadań.
Ant jest napisany całkowicie w Javie.
Wykład 1
Wykład 1 – p. 21/24
Apache Ant - przykładowy plik build.xml
<?xml version="1.0" encoding="iso-8859-2"?>
<project name="first" basedir="." default="compile">
<path id="log4jclasspath">
<pathelement location="${basedir}"/>
<pathelement location="/../wspolne.jar"/>
</path>
Kontrola wersji
Kod ewoluuje. W czasie gdy projekt zmienia sie˛ z prototypu w wersje˛
ostateczna˛ przechodzi przez wiele cykli, w których programiści
badaja˛ nowe trendy, usuwaja˛ błedy
˛ i stabilizuja˛ swoje osiagni
˛ ecia.
˛
Ewolucja kodu powoduje wiele problemów, które moga˛ być źródłem
konfliktów i dodatkowej pracy, zmniejszajac
˛ w ten sposób
efektywność.
<target name="compile">
<javac srcdir="."
classpathref="classpath"
/>
</target>
Jednym z ważniejszych problemów jest możliwość powrotu do starej
wersji.
Równie ważna jest możliwość rejestracji zmian.
Kolejnym problemem jest śledzenie błedów.
˛
Cz˛esto otrzymywany
jest raport o błedzie
˛
w konkretnej wersji programu, podczas
<target name="run">
<java
classpathref=""
classname="org.gridwise.Simple"
/>
</target>
</project>
Wykład 1 – p. 23/24
Wykład 1