czwartek, 9 października 2008

CMake w Ubuntu Hardy

Instalacja CMake z domyślnych repozytoriów w Ubuntu 8.04 nie daje satysfakcjonujących efektów - brakuje nam dwóch aplikacji: ccmake i cmake-gui. Pierwsza z nich to interfejs konsolowy (biblioteka: ncurses), natomiast druga to interfejs okienkowy (biblioteka: Qt).

Lepiej już sytuacja wygląda gdy sami skompilujemy wersję źródłową. Pojawia się ccmake, ale ciągle nie ma cmake-gui.

Dlatego najlepszym rozwiązaniem wydaje się skorzystanie z przygotowanej wersji binarnej, którą możemy pobrać ze strony projektu. Po pobraniu rozpakowujemy archiwum i przechodzimy do katalogu:

tar -xzvf cmake-2.6.2-Linux-i386.tar.gz
cd cmake-2.6.2-Linux-i386/

W następnym kroku kopiujemy poszczególne katalogi w odpowiednie miejsca w naszej strukturze plików:

sudo cp bin/* /usr/bin/
sudo cp -R doc/cmake-2.6/ /usr/share/doc/
sudo cp -R man/man1/ /usr/share/man/
sudo cp -R share/* /usr/share/

Teraz już powinno wszystko działać bez zarzutów. Warto sprawdzić czy programy cmake, ccmake, cmake-gui są dostępne z linii komend i czy w Aplikacjach, w dziale Programowanie widnieje skrót do cmake.

3 komentarze:

Rafał Petryniak pisze...

Tak się właśnie zastanawiałem gdzie to powinno być. Aby mieć pewność, że będzie to chodziło w miarę bezproblemowo, sprawdziłem w Synapticu, gdzie są kopiowane pliki instalowane z repozytorium i tam umieściłem te z archiwum.

Student pisze...

Jeśli można coś dodać: Zazwyczaj z prefixem /usr budowane sa biblioteki/programy/etc. zawarte w pakietach binarnych. Dla software'u instalowanego ze źródeł lub kopiowanego ręcznie do systemu plików o wiele lepszą lokalizacją jest /usr/local. Dlaczego? Po pierwsze zabezpieczamy się przed sytuacją gdzie następuje wymieszanie/nadpisanie bibliotek czy binarek (menedżer pakietów po takiej instalacji nie ma pojęcia o istnieniu (c)cmake instalowanego ręcznie) co może spowodowac problemy (dziś tych narzędzi nie ma w repozytorium dystrybucji ale co może być w przyszłości? Pamiętanie o takich rzeczach i przeczesywanie list pakietów do aktualizacji nie jest najlepszym rozwiązaniem). Drugi powód - kolejność występowania katalogów w zmiennej środowiskowej $PATH - /usr/local/bin zazwyczaj występuje przed /usr/bin (jeśli nie na samym początku, poza root'em (opeiram się na dośł. z gentoo), który z wiadomych przyczyn ma ograniczona zmienną $PATH (co nie oznacza, że nie możemy jej wyeksportować chociażby w ~/.bashrc root'a)). Powoduje to że programy w /usr/local/bin mają pierwszeństwo, co bywa przydatne w pewnych specyficznych przypadkach.

Pozdrawiam

Marcin Kubala pisze...

Zapomniałem o jeszcze jednej wążnej kwestii dotyczącej instalacji "z palca" - jeśli kompilujemy jakąś bibliotekę, która jest wymagana do budowy/działania innego programu, a ten pochodzi np. z binarek, został zainstalowany z innym prefiksem - np. /opt (w niektórych dystrybucjach tam znajduje się kde, qt, u mnie akurat jest to /usr/kde/wersja) lub ./configure nie przechodzi bo nie widzi naszej świeżo zainstalowanej biblioteki (bo szuka w /usr, a nie /usr/local) to nie mamy powodu zalamywac rąk. Do rozwiązywania tego typu problemów służy konsolidator dynamiczny. Wystarczy dodać ścieżkę do katalogu z bibliotekami do pliku /etc/ld.so.conf i uruchomić polecenie ldconfig.

Prześlij komentarz