Plan wykładów. Oprogramowanie i wykorzystanie stacji roboczych. Wykład 1. Konkurs programistyczny. Literatura. Dr inż. Tomasz Olas

Transkrypt

1 Plan wykładów Oprogramowanie i wykorzystanie stacji roboczych Dr inż. Tomasz Olas olas@icis.pcz.pl Wybrane narzędzia 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 Instytut Informatyki Teoretycznej i Stosowanej Politechnika Częstochowska p. 1/24 Literatura Konkurs programistyczny N. Matthew, R. Stones: Zaawansowane programowanie w systemie Linux, Helion, D. Solin: Poznaj programowanie przy u yciu biblioteki Qt w 24 godziny, Infoland, J. D. Folley i inni: Wprowadzenie do grafiki komputerowej, WNT. R. S. Wright jr, M. Sweet: OpenGL księga ekperta. Helion, 1999 P. Andrzejewski, J. Kurzak: Wprowadzenie do OpenGL, Kwantum Witryna internetowa projektu OpenGL: B. Lewis, D. J. Berg: Multithreaded Programming with Pthreads, Sun Microsystems Press, B. Nichols, D. Buttlar: Pthreads Programming, O Reilly Adres strony www konkursu: p. 3/24

2 Konstrukcja wielomodułowa programów Make Zapewnia logiczna strukturę 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 języku C/C++ procedur napisanych w innych językach programowania. Zwiększa szybkość kompilacji w trakcie modyfikowania programu. Make jest narzędziem automatycznie określajacym, które fragmenty kodu wymagaja ponownej kompilacji i wykonuje ich kompilację. Plik makefile (Makefile) - opisuje relacje pomiędzy 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ć się w pierwszej kolumnie tekstu, natomiast polecenia musza być poprzedzone co najmniej jednym znakiem pustym. p. 5/24 Make - reguły Make - makrodefinicje Można rozróżnić dwa rodzaje reguł: Reguły jawne: zbiór_uakt [zbiór_uakt [...]]: {{ścieżki}][zbiór-uzal...] polecenie 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.c.o: gcc -c $< Definiowanie makrodefinicji: nazwa_makrodefinicji=tekst_rozwinięcia PROGRAM=bierki OBJS=foo.c Rozwijanie makrodeficji: $(nazwa_makrodefinicji) $(PROGRAM): $(OBJS) g++ -c $(OBJS) -o $(PROGRAM) p. 7/24

3 Make - makrodefinicje predefiniowane Make - przykład $* - Makro to rozwija się w nazwę zbioru uzależniajacego (ze ścieżka dostępu, lecz bez rozszerzenia). $< - Makro to działa tak jak $*, z ta różnica, że uzyskana nazwa zbioru zawiera rozszerzenie. $@ - Makro to rozwija się w nazwę zbioru uzależnianego (wraz z jego rozszerzeniem). $: - Ta makrodefinicja rozwija się w ścieżkę dostępu do zbioru, ale bez jego nazwy. Jeśli występuje w regułach jawnych, to uzyskana zostanie ścieżka zbioru docelowego, w niejawnych zaś ścieżka zbioru przetwarzanego. PROJECT = bierki INC =./include INSTALLBIN = $(HOME)/opt/bin CXX = g 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) p. 9/24 ake - automatyczne generowanie zależności Make - reguły standardowe 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ładowe wygenerowane 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 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 p. 11/24

4 Narzędzia wspierajace program make GNU Autoconf (I) makedepend - służy do automatycznego generowania zależności pomiędzy plikami w projekcie. Dostarczany razem z systemem X Window. Imake - służy do mechanicznego generowania plików makefile dla systemu X. Opiera się na wywołaniu programu makedepend autoconf - generuje skrypt powłoki configure dopasowany do projektu. automake - narzędzie podobny do autoconf - umożliwia generowanie plików makefile, posiadajacy jednak wbudowane mechanizmy badania zależności (podobna do programu Imake). tmake - narzędzie firmy TrollTech pierwotnie utworzone dla biblioteki Qt, ale może być wykorzystywane również w innych projektach. Autoconf jest narzędziem (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ędzia 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 się narzędzia, biblioteki, pliki nagłówkowe niezbędne do poprawnego utworzenia programu. Po określeniu środowiska w którym kompilowany jest program skrypt ten powinien wygenerować odpowiednie definicje i opcje kompilacji. Często narzędzie Autoconf jest stosowany w połaczeniu z programami Automake i Autoheader. p. 13/24 GNU Autoconf (II) Tworzenie skryptu configure 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 się 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 języku Bourne shella. 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. p. 15/24

5 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 LDFLAGS endif $(OBJ)/%.o: $(SRC)/%.cpp $(CXX) -c $(CXXFLAGS) -o $@ $< $(PROGRAM): $(OBJS) $(CXX) -o $(PROGRAM) $(LDFLAGS) $(OBJ) p. 17/24 Jam Jam kontra Make Jednym z ciekawszych projektów, które w przyszłości moga zastapić program make jest Jam. Zalety: Zwiększenie projektu nie prowadzi do tak drastycznego zwiększania się 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). 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 ; p. 19/24

6 Apache Ant (I) Apache Ant (II) Apache Ant jest częścia projektu Apache Jakarta. Opiera się 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 języka 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 językach programowania (również w C++). Ant jest napisany całkowicie w Javie. Plik konfiguracyjny dla programu Ant jest plikiem w formacie XML. Zazwyczaj nosi nazwę build.xml. Składa się 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 się z dowolnej ilości wykonywanych zadań <task>. Jest to prosta czynność, która będzie 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ń. p. 21/24 Apache Ant - przykładowy plik build.xml Kontrola wersji <?xml version="1.0" encoding="iso "?> <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> p. 23/24 Kod ewoluuje. W czasie gdy projekt zmienia się z prototypu w wersję ostateczna przechodzi przez wiele cykli, w których programiści badaja nowe trendy, usuwaja błędy i stabilizuja swoje osiagnięcia. Ewolucja kodu powoduje wiele problemów, które moga być źródłem konfliktów i dodatkowej pracy, zmniejszajac w ten sposób efektywność. 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łędów. Często otrzymywany jest raport o błędzie w konkretnej wersji programu, podczas