Oprogramowanie i wykorzystanie stacji roboczych Wykład 1

Oprogramowanie i wykorzystanie
stacji roboczych
Wykład 1
Dr inż. Tomasz Olas
[email protected]
Instytut Informatyki Teoretycznej i Stosowanej
Politechnika Cz˛estochowska
Wykład 1 – p. 1/2
Plan wykładów
Wybrane narz˛edzia wspomagajace
˛ proces tworzenia
oprogramowania
Podstawy systemu X Window
Biblioteka Qt
Tworzenie grafiki trójwymiarowej na przykładzie blioteki OpenGL
Programowanie wielowatkowe
˛
Poprawa wydajności oprogramowania
Wykład 1 – p. 2/2
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.
Wykład 1 – p. 3/2
Konkurs programistyczny
Adres strony www konkursu: www.power.com.pl/pl/konkurs
Wykład 1 – p. 4/2
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.
Umożliwia wykorzystywanie w programie w jezyku
˛
C/C++ procedur
napisanych w innych jezykach
˛
programowania.
Zwieksza
˛
szybkość kompilacji w trakcie modyfikowania programu.
Wykład 1 – p. 5/2
Make
Make jest narz˛edziem automatycznie określajacym,
˛
które fragmenty
kodu wymagaja˛ ponownej kompilacji i wykonuje ich kompilacje.
˛
Plik makefile (Makefile) - opisuje relacje pomiedzy
˛
plikami w
projekcie oraz polecenia służace
˛ do uaktualniania poszczególnych
plików.
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 – p. 6/2
Make - reguły
Reguły (rules) opisuja˛ kiedy i w jaki sposób należy „odświeżać” pliki.
Można rozróżnić dwa rodzaje reguł:
Reguły jawne:
zbiór_uakt [zbiór_uakt [...]]: {{ścieżki}][zbiór-uzal ...]
polecenie
przykład:
foo.o : foo.c defs.h
gcc -c -g foo.c
Reguły niejawne:
[katalog_źródł]\%.rozsz_źródł: [katalog_docelowy]\%.rozsz_docelowe:
polecenie
przykład:
%.o: %.c
gcc -c $<
Wykład 1 – p. 7/2
Make - makrodefinicje
Definicja:
nazwa_makrodefinicji=tekst_rozwini˛
ecia
przykład:
PROGRAM=bierki
OBJS=foo.c
Rozwiniecie:
˛
$(nazwa_makrodefinicji)
przykład:
$(PROGRAM): $(OBJS)
g++ -c $(OBJS) -o $(PROGRAM)
Wykład 1 – p. 8/2
Make - makrodefinicje predefiniowane
$* - makro to rozwija sie˛ w nazw˛e zbioru uzależniajacego
˛
(ze
ścieżka˛ dostepu,
˛
lecz bez rozszerzenia),
$< - działa tak jak $*, z ta˛ różnica,˛ że uzyskana nazwa zbioru
zawiera rozszerzenie,
$@ - rozwija sie˛ w nazw˛e zbioru uzależnianego (wraz z jego
rozszerzeniem),
$: - 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.
Wykład 1 – p. 9/2
Make - przykład
PROJECT = bierki
INC
=
./include
INSTALLBIN = $(HOME)/opt/bin
CXX = g++-2.95
CXXFLAGS += -I$(INC)
OBJS = $(PROJECT).o okno.o
all: $(PROJECT)
%.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 – p. 10/2
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.
Przykład:
depend:
$(CXX) -MM $(CXXFLAGS) *.cpp > depend.mk
...
include depend.mk
Przykład wygenerowanych zależności:
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
Wykład 1 – p. 11/2
Make - reguły standardowe
Istnieje zbiór reguł, których stosowanie powoduje, że pliki makefile sa˛
znacznie prostsze do zrozumienia i stosowania:
all,
test,
clean,
dist,
distclean,
realclean,
install,
uninstal.
Wykład 1 – p. 12/2
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.
Wykład 1 – p. 13/2
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 – p. 14/2
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.
Plik konfiguracyjny tworzy sie˛ w oparciu o makra sprawdzajace:
˛
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.
Wykład 1 – p. 15/2
Tworzenie skryptu configure
W celu wygenerowania skryptu configure należy utworzyć plik
konfiguracyjny dla programu Autoconf: configure.ac (lub
configure.in).
Przykładowa struktura pliku configure.ac:
Uworzenie pliku configure nastapi
˛ po uruchomieniu programu
autoconf.
Wykład 1 – p. 16/2
Autoconf - przykład (I)
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
Wykład 1 – p. 17/2
Autoconf - przykład (II)
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. 18/2
Jam
Jednym z ciekawszych projektów, które w przyszłości moga˛ zastapić
˛
program make jest Jam.
Zalety:
Zwiekszenie
˛
projektu nie prowadzi do tak drastycznego zwiekszania
˛
sie˛ pliku
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.
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).
Może być dowolnie konfigurowany poprzez tzw. reguły (Jamrules).
Wykład 1 – p. 19/2
Jam kontra Make
Plik konfiguracyjny dla programu Make:
progam: data.o main.o io.o
gcc data.o main.o io.o -o progam
data.o: data.c
gcc -c data.c
main.o: main.c
gcc -c main.c
io.o: io.c
gcc -c io.c
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. 20/2
Apache Ant (I)
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++).
Ant jest napisany całkowicie w Javie.
Wykład 1 – p. 21/2
Apache Ant (II)
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ń.
Wykład 1 – p. 22/2
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>
<target name="compile">
<javac srcdir="."
classpathref="classpath"
/>
</target>
<target name="run">
<java
classpathref=""
classname="org.gridwise.Simple"
/>
</target>
</project>
Wykład 1 – p. 23/2