<p>
W zamierzchłych czasach gdy komputery znajdowały się w zasięgu
uczelni wyższych, nawet oprogramowanie własnościowe było
- rozprowadzane w ten sposób. Dawniej chcać skorzystać z programu
+ rozprowadzane przy użyciu kodu źródłowego. Dawniej chcać skorzystać z
+ programu
trzeba było wyposażyć się w zestaw narzędzi programistycznych aby
- móc w ogółe go uruchomić. Czy te czasy minęły? I tak i nie. Obecnie
+ móc w ogóle go uruchomić. Czy te czasy minęły? I tak i nie. Obecnie
w wielu dystrybucjach częściej stosuje się paczki przygotowywane
osoby związane z dystrybucją aniżeli archiwa kodu niezależnie
rozprowadzane przez autora programu. Ma to oczywiście swoje wady oraz
</p>
<h2 id="15.1.softwarebuildsystems">15.1. Systemy do budowania oprogramowania</h2>
<p>
- Jak pamietam z poprzedniego rozdziału do automatycznego stworzenia
+ Jak pamietamy z poprzedniego rozdziału do automatycznego stworzenia
pliku wykonywalnego dla naszej przykładowej aplikacji
wykorzystaliśmy narzędzie <em>make</em>, narzędzie to wymaga pliku
<em>Makefile</em>, w którym to zapisywane były cele, zależności czy
- różnego rodzaju makra. Jednym system budowania oprogramowania
+ różnego rodzaju makra. Jednym z systemów budowania oprogramowania
dostępnym na Uniksy jest <strong>GNU autoconf</strong>. Zadaniem
skryptów tego narzędzia jest przygotowanie plików <em>Makefile</em>
na podstawie analizy docelowego systemu. System ten korzysta z
zachować pewną dozę niepewności. Otóż zadajmy sobie proste pytanie.
Co odróżnia program przydatny od szkodliwego oprogramowania?
Odpowiedź jest prosta. Czynności jakie on wykonuje. Na pewnej
- płaszczyźnie jedno i drugie to programy, które nom men omen mogą
+ płaszczyźnie jedno i drugie to programy, które mogą
być rozporowadzane w postaci kodu źrodłowego, który zostanie być może
zostanie przez nas pobrany, skompilowany i zainstalowany w systemie.
Najczęstszym tego typu oprogramowaniem są konie trojańskie. Dlatego
</p>
<h2 id="15.3.gnuautconf">15.3. GNU autoconf</h2>
<p>
- Jeśli kiedy uczyliśmy się jezyka C, to wiemy że jest on przenośny
+ Jeśli kiedyś uczyliśmy się jezyka C, to wiemy że jest on przenośny
między systemami, jednak między systemami operacyjnymi czy
platformami sprzętowymi instnieje tak wiele różnic, że najczęściej
użycie pojedynczego pliku <em>Makefile</em> nie wykonana poprawnie
szablonami.
</p>
<p>
- Natomiast sama koncepcja jest dość prosta. Polega ona na uruchomienie
+ Natomiast sama koncepcja jest dość prosta. Polega ona na uruchomieniu
pliku <em>configure</em>, który sprawdzi system i dokona odpowiednich
podstawień w pliku <em>Makefile.in</em>, tworząc odpowiedni plik
<em>Makefile</em> dla uruchomionego systemu oraz platformy
<p>
W czasie działania skryptu zostanie nam wyświetlona duża ilość
komunikatów diagonstycznych. Jeśli działanie skryptu zakończy się
- powodzeniem, to wówczas zostanie wygenerowany co najmniej jedem
+ powodzeniem, to wówczas zostanie wygenerowany co najmniej jeden
pliki <em>Makefile</em>, <em>config.h</em> oraz <em>config.cache</em>.
Dzięki czemu nie ma potrzeby przeprowadzania wszystkich testów
ponownie w przypadku kolejnego uruchomienia skryptu.
make[1]: Leaving directory '/home/xf0r3m/Pobrane/coreutils-9.5'
</pre>
<p>
- Po podaniu za pomocą opcji <em>--prefix</em>,
- narzędzie <em>make</em> zainstalowało
+ Po podaniu za pomocą opcji <em>--prefix</em> miejsca docelowego
+ dla programów, narzędzie <em>make</em> zainstalowało
zbudowane pliki wykonywalne we wskazanym w opcji katalogu. A tak
prezentuje się zawartość tego katalogu:
</p>
Istnieje możliwość instalacji kompilowanego oprogramowania w taki
sposób, aby można było je kontrolować za pomocą mendżera paketów
dystrybucji. Dystrybucjami, w których najprościej jest wykonać to
- zadanie są te oparte na Debianie, ze względu na prostotę twowrzenia
+ zadanie są te oparte na Debianie, ze względu na prostotę tworzenia
pakietów <em>.deb</em>. W tym celu posłużymy się narzędziem
<strong>checkinstall</strong>.
Domyślnie może nie występować w naszym systemie, ale możliwe jest
wykonywalne będą instalowane w podanym <em>katalogu</em>.</li>
<li><strong>--disable-shared</strong> - opcja ta zakazuje tworzenia
bibliotek współdzielonych. Ta opcja może pomóc w zapobiegnięciu
- problemów z bibliorekami współdzielonymi.</li>
+ problemów z bibliotekami współdzielonymi.</li>
<li><strong>--with-<em>pakiet</em>=<em>katalog</em></strong> - ta
opcja służy do wskazania bibliotek zainstalowanych w
niestandardowej lokalizacji. Jednak nie wszystkie skrypty
do własnych potrzeb.
</p>
<p>
- Zmienne środowiskowe możemy podawać przed w tym samy wierszu
+ Zmienne środowiskowe możemy podawać w tym samy wierszu
polecenia przed uruchomieniem skryptu:
</p>
<pre class="code-block">
Działanie programu <em>pkg-config</em> opiera sie o pliki
<em>.pc</em>, które mogą być rozprowadzane w pakietach naszej
dystrybucji w momencie instalacji bibilioteki, oczywiście zarządca
- pakietu musi utworzyć taki pliki. Polecenie przeszukuje katalog
+ pakietu musi utworzyć taki plik. Polecenie przeszukuje katalog
<em>lib/pkg-config</em> swojego przedrostka instalacji (prefiksu),
jeśli np. jego prefiksem jest <em>/usr</em>, to będzie on
przeszukiwać katalog <em>/usr/lib/pkg-config</em>.
Jeśli chcemy dodać do zasobów <em>pkg-config</em> bibliotekę o
niestandardowym miejscu instalacji, to możemy wykorzystać do tego
dwie metody. Pierwsza z nich jest zwykłą kopią pliku <em>.pc</em>
- do domyślnego katalogu narzędzia lub utworzenia dowiązania
+ do domyślnego katalogu narzędzia lub utworzenie dowiązania
symbolicznego. Drugą opcją jest uzupełnienie zmiennej
<em>PKG_CONFIG_PATH</em>, o dodatkowy katalog. Jednak to rozwiązanie
niesprawdza się w obrębie całego systemu.
</p>
<h2 id="15.4.manualinstallationprosandcons">15.4. Zalety i wady ręcznej instalacji</h2>
<p>
- Na poziomie podstawowym osbsługi systemów Linuksowych, nikt nie
+ Na poziomie podstawowym obsługi systemów Linuksowych, nikt nie
pownien od was wymagać umiejętności ręcznej instalacji oprogramowania
w systemie. Raczej będziemy polegać na tym co oferują nam repozytoria
dystrybucji. Obecnie dostawcy różnych programów często przygotowują
pakiety systemu zarządzania oprogramowaniem dla wielu wiodących
dystrybucji, dlatego też ręczna instalacja spada do rangi pewnego
rodzaju niszy. Budowanie może zająć naprawdę wiele czasu i nie
- zawsze mozemy osiągnąć ządany skutek. Chcemy skompilować jakiś
+ zawsze mozemy osiągnąć żądany skutek. Chcemy skompilować jakiś
program, okazuje się że brakuje nam bibliotek w takiej wersji, więc
musimy przeprowadzić kompilację bibliotek w takiej wersji w ten
- sposób nasza praca związana tym zagadnieniem się nawarstawia.
+ sposób nasza praca związana tym zagadnieniem się nawarstwia.
Weźmy pod uwagę też sprzęt. Nie każdy dysponuje potężną maszyną,
która będzie wstanie kompilować duże programy w ciągu kilku minut.
Większość użytkowników dystrybucji Linuksa, do których adresowany
jest ten materiał, raczej korzysta z budżetowego laptopa z marketu.
- Uciekła do MS Windows, w celu polepszenia swoich doświadczeń z
+ Ucieczka do MS Windows, w celu polepszenia swoich doświadczeń z
komputerem, bez reklam czy najważniejszej rzeczy w tym systemie czyli
aktualizacji. Tak więc kompilacja na takim sprzęcie może zająć
dłuższą chwilę, co sprawia, że budowanie od podstaw oprogramowania
<p>
Nie mniej jednak taka instalacja oprogramowania w systemie nie jest
bez zalet. Najważniejszymi z nich jest dostarczenie do naszych
- systemów najnowszych wersji programów, dostosowania ich możliwości
+ systemów najnowszych wersji programów, dostosowanie ich możliwości
oraz funkcjonalności przy użyciu opcjonalnych bibliotek czy samych
opcji kompilacji do naszych potrzeb. Nawet lepiej, istnieją całe
dystrybucje, które opierają się tylko i wyłącznie o ręczną instalację
</p>
<h2 id="15.5.usingpatches">15.5. Stosowanie poprawek</h2>
<p>
- Poprawki są nieodłącznym elementem życia oprogramowania. Poprawki
- są dystrybułowane za pomocą takich narzędzi jak system kontroli
+ Poprawki są nieodłącznym elementem życia oprogramowania. Są one
+ dystrybuowane za pomocą takich narzędzi jak system kontroli
wersji <em>Git</em>. Mogą one wprowadzać szereg zmian do kodu
źródłowego, poprawiać błedy lub uzupełaniać oprogramowanie o nowa
funkcjonalność. Poprawki tworzone są zapomocą polecenia
- <em>diff</em>. Poniżej znajduje się nagłówek pliku poprawki
+ <strong>diff</strong>. Poniżej znajduje się nagłówek pliku poprawki
wprowadzający zamiany, które obecnie czytasz do tego materiału.
</p>
<pre class="code-block">
<p>
Pliki poprawek są tworzone za pomocą polecenia <em>diff</em>,
natomiast instalowane są za pomocą polecenia <strong>patch</strong>.
- Przyczym podczas instalacji poprawek istotne jest dobre umieszczenie
- poprawki w katalogu z kodem źródłowym. Załóżmy, że mamy plik
+ Przyczym podczas instalacji poprawek istotne jest dobre ustawie
+ katalogu roboczego w folderze z kodem źródłowym. Załóżmy, że mamy
+ plik
poprawki, który obejmuje plik <em>src/plik.c</em>. Wówczas taki
plik poprawki należy nałożyć w katalogu nadrzędnym katalogu
<em>src</em>, wydając poniższe polecenie:
projects / mmdev.git / commitdiff