CMake - nowy system budowania KDE
Kiedy projekt taki jak KDE staje się tak duży jak KDE w tym momencie zmiana decyzji podjętej prawie dekadę temu jest bardzo trudna. KDE od samego początku wykorzystywało autotools do budowania większej części pakietów, ale KDE 4 wykorzystuje już CMake.
Ten artykuł skupia się na CMake, który nie jest częścią KDE, ale jest rozwijany przez Kitware i innych niezależnych programistów. Jest on udostępniany na licencji w stylu BSD. Niestety nie mogę pokazać żadnych zrzutów ekranów, ale postaram się jak najlepiej wytłumaczyć dlaczego zdecydowano się na wykorzystanie CMake w procesie budowania KDE.
Zanim omówię CMake - troszkę historii KDE i autotools. KDE od początków istnienia wykorzystuje Qt, a jedną z fajnych cech Qt jest kompilator meta-obiektów (ang. meta-object compiler (moc)). Autotools ma możliwość wykorzystania moc jako pre-procesora dla plików nagłówkowych KDE. To były dopiero początki - programiści KDE napisali także oprogramowanie wykorzystujące protokół DCOP, dzięki czemu podczas procesu budowania KDE można było generować kolejne typy plików. Dodano także kompilator dokumentacji, plików z tłumaczeniami oraz narzędzia które "tłumaczyły" pliki konfiguracyjne z XMLa - powstał kompilator interfejsu użytkownika Qt (dla plików .ui) i musiał on być wspierany w procesie kompilacji KDE. Powstała także potrzeba dodania całej masy różnych opcji i przełączników, które były wykorzystywane przez KDE. System budowania stał się bardzo rozbudowany i autotools okazało się niewystarczające.
W KDE 3 jedynie kilku programistów rozumiało całość systemu budowania KDE. Programiści chąc choćby przenieść jakieś plik do innego folderu musieli spędzić godziny aby sprawić, że KDE będzie się znowu kompilowało. Czasami nawet dla prostej aplikacji "Hello World!" należało napisać 500 kilobajtów kodu, aby był wspierany przez autotools.
Oczywistym stało się, że wraz z wprowadzeniem KDE 4 należy poprawić tą sytuację. Na konferencji Akademy 2005 zadecydowano, że do budowania należy wykorzystać inny system. Początkowo zdecydowano się na SCons, lecz był on bardzo powolny a po kilku miesiącach pracy pakiet kdelibs nadal się nie kompilował. Jednym z większych problemów SCons jest brak jego modularności.
W wyniku niepowodzeń ze SConsem Alexander Neundorf zdecydował się na wykorzystanie CMake i okazało się, że działa on bardzo dobrze. Po kilku miesiącach pracy całe KDE kompilowało się przy pomocy CMake i można było całkowicie porzucić autotools.
Programiści CMake bardzo pomagali podczas portowania KDE na CMake. Powstała nawet specjalna lista mailingowa. Współpraca ta przyniosła korzyści obu projektom. Kiedy pojawiał się jakiś problem programiści KDE często proponowali poprawki do CMake.
CMake usprawniło proces budowania KDE. Projekty korzystające z CMake rozwijają się szybciej ponieważ należy poświęcić mniej czasu na "walke" z systemem budowania.
Kiedy wpisujemy komendę "cmake" program przetwarza plik "CMakeLists.txt" (który musi być umieszczony w katalogu ze źródłami) i generuje plik Makefile (na systemach UNIXowych) lub pliki XCode (na systemie Mac). CMake potrafi także wygenerować pliki projektu programu KDevelop, opierając się tylko na pliku "CMakeLists.txt".
Kod KDE już wcześniej był w miarę przenośny, ale ze względu na brak autotools dla Windowsa nie dało się go skompilować w tym środowisku. Aktualnie właśnie dzięki nowemu systemowi budowania jest to możliwe (i oczywiście dzięki udostępnieniu Qt na licencji GPL na tych platformach).
Aby skompilować KDE z serii 3 należało wydać mniej więcej takie komendy:
% ./configure --prefix=/foo --enable-debug % make # make install
Jak widać jest to ładna, standardowa składnia w projektach, które używają autotools.
W KDE 4, korzystającym z CMake, składnia jest już nieco inna (może być troszkę mniej oczywista), ale komendy są w większości takie same.
% cmake -DCMAKE_INSTALL_PREFIX=/foo \
-DCMAKE_BUILD_TYPE=debugfull .
% make
# make install
CMake wyszukuje zależności klika razy szybciej niż robiła to komenda "./configure". CMake buduje kdelibs z KDE 4 około 40% szybciej niż autotools kdelibs z KDE 3.5.6, głównie ze względu na brak biblioteki libtools w CMake. CMake wykonuje następujące kroki (w systemach UNIXowych): cmake + make a autotools dla KDE 3.5.6: automake + autoconf + libtool + make + sh + perl + m4.
Zamierzam przedstawić o ile łatwiejszy w użyciu jest CMake: Aaron Seigo poprosił mnie o pomoc w portowaniu komponentów kdesktop, aby można było ostatecznie zrezygnować z kdesktop w KDE 4. Jest to zadanie, którego w KDE 3 bym się nie podjął - nie dlatego, że jest ciężkie w wykonaniu, ale dlatego, że nie umiałbym dostosować kodu tak, aby system budowania KDE sobie z nim poradził. Po poprawieniu kodu źródłowego i zmienieniu nazw kliku klasom po prostu dodałem prawidłowy kod do systemu budowania. Wystarczyła modyfikacja zaledwie dwóch czy trzech linijek w pliku konfiguracji CMake dla krunnera. Po kilku minutach program był skompilowany i zainstalowany. W KDE 3 prawdopodobnie nie poradziłbym sobie z systemem budowania i poddał nie zatwierdzając moich poprawek w repozytorium SVN.
Przykład ten pokazuje, że CMake jest o wiele łatwiejszy w obsłudze i praktycznie każdy sobie z nim poradzi. Wielu programistów ma podobne odczucia: składnia "CMakeLists.txt" jest o wiele bardziej przejrzysta niż składnia "autotools". Jak na razie większość osób pracujących przy KDE nie ma zbyt dużego doświadczenia z CMake, lecz programiści CMake osobiście sprawdzają, czy proces budowania KDE przebiega prawidłowo.
Przejście na CMake nie jest pierwszą większą zmianą podczas rozwoju KDE. Wcześniej KDE wykorzystywało repozytorium CVS do kontroli nad kodem źródłowym. Zarządzanie serwerem CVS kiedy projekt się rozrósł stało się coraz trudniejsze. Subversion (SVN) oferowało o wiele lepsze rozwiązania, bardziej dostosowane do wymagań KDE. Aktualnie KDE jest największym projektem wykorzystującym repozytorium SVN, ta migracja była dla niego prawdziwym testem. Od czasów migracji KDE wiele innych projektów zdecydowało się na wykorzystanie SVN.
Wykorzystanie CMake przez KDE nieco rozpropagowało ten projekt. Wiele innych projektów zaczęło używać tego systemu budowania. Są to między innymi projekty takie jak: Scribus, Rosegarden, PlPlot, ChickenScheme i wiele innych. Projekty, które poszukują łatwego sposobu na budowanie na wielu platformach powinny wypróbować CMake. Dodanie do repozytorium pliku "CMakeLists.txt" na pewno nie przeszkodzi staremu systemowi budowania a pozwoli na zapoznanie się z CMake. Jeśli CMake nie będzie mógł podołać jakimś wymaganiom to programiści CMake są otwarci na poprawki i ulepszenia.
Więcej informacji:
W tym tygodniu to tyle i obiecuję, że nastepnym razem zaprezentuję bardziej efektowne rzeczy...
