Czym jest zintegrowane środowisko
programistyczne(IDE) nie trzeba tłumaczyć. Do najpopularniejszych
należą Visual Studio, Eclipse, NetBeans, QTCreator, Borland
Developer Studio, Xcode. Posiadają wiele przydatnych narzędzi do
refaktoringu kodu, podpowiadają składnie, indeksują symbole w
obrębie projektu, integrują się z systemem kontroli wersji i
posiadają tysiące funkcji „ułatwiających” codzienną pracę.
Skoro są takie cudowne to czy można
im coś zarzucić? Moja odpowiedź brzmi TAK. A jest to przede
wszystkim konfiguracja projektu do pracy z zewnętrznymi
niestandardowymi bibliotekami i sposób budowania. W większości
wymienionych środowisk nie jest generowany automatycznie plik
makefile, ustawienia sposobu budowy projektu i linkowania zaszyte są
gdzieś po zakładkach, i opcjach konfiguracyjnych. Jestem
jednocześnie świadom że każde z tych środowisk pozwala na
wczytanie własnego makefila i na jego podstawie potrafi utworzyć,
zindeksować projekt, tym nie mniej nie jest to opcja domyślna.
Dodanie odpowiednich bibliotek (np. opencv/boost) do projektu VS to
prawdziwa droga przez mękę, zresztą w Eclipsie nie jest wcale
lepiej. A przecież można inaczej. Wystarczy utworzyć plik Makefile
i w nim umieścić odpowiednie informację np.: nazwa i ścieżka do
kompilatora, flagi kompilacji, opcje linkera. Wszystko to w jednym
miejscu, jasno prosto i przejrzyście.
Czy rzeczywiście jest tak źle? Tak
naprawdę wszystko to jest osiągalne z poziomu IDE. Konfiguracja
zazwyczaj zebrana jest w jednym miejscu i nie jest aż tak uciążliwa,
wykonuje się ją raz na początku projektu. Jaka jest zatem przewaga
makefile nad systemem budowania dostarczanym przez IDE?
Dla małych projektów, niedużej
ilości developerów bądź też pracy hobbistycznej sprawa nie jest
oczywista. Problem zaczyna pojawiać się w momencie w którym chcemy
budować nasz projekt na maszynie nie będącej stacją developerską.
Na takiej maszynie należałoby zainstalować odpowiednie IDE,
kompilator, biblioteki, i w jakiś sposób uruchomić build ze
wszystkimi zależnościami, ścieżkami itp..
A co w przypadku gdy mamy do czynienia
z makefilem? No cóż instalujemy kompilator i biblioteki zaciągami
projekt i budujemy.
Sytuacja staje się znacznie bardziej
złożona gdy mamy do czynienia z systemem ciągłej integracji
(continus integration). Dla takich systemów rozpoczyna się
poszukiwanie odpowiednich wtyczek, czytanie dokumentacji, wyciąganie
konfiguracji z projektowych plików xml, pisanie skryptów. Innymi
słowy horror jakich mało (na potwierdzenie swoich słów proponuje
każdemu kto ma możliwość skonfigurować Jenkinsa z Xcodem oraz
projektem na iOs'a). Makefile pozwoli nam na szybkie wykonanie
builda. Dla klasycznego make budowa staje się prosta, wystarczy
przecież wpisać make i wszystko zrobione. Zazwyczaj nie są nawet
wymagane korekcje ścieżek. Co więcej jeżeli projekt korzysta ze
standardowych bibliotek dostępnych na wielu systemach istnieje spora
szansa że uda się go przenieść z jednego systemu operacyjnego na
inny podmieniając jedynie nazwę kompilatora. Można sobie wyobrazić
przeniesienie projektu napisanego na windowsie z wykorzystaniem
bibliotek takich jak boost, opencv na linuxa. Każdy kto kiedyś
próbował wie w czym problem. Innymi słowy jeżeli mam możliwość
wyboru IDE, wybieram takie które pozwoli mi korzystać z zewnętrznego
makefila. Daje mi to pełną kontrolę nad tym co się dzieje podczas
procesu budowania i umożliwia szybkie modyfikowanie flag kompilacji.
Ponadto sprawia że współpraca z systemem ciągłej integracji
staje się zazwyczaj bajecznie prosta.
Komentarze
Prześlij komentarz