Django na ARM-ie
Dziś kontynuuję wątek Linuksa na ARM-ie, a konkretnie na płycie ewaluacyjnej MMnet1002. W projekcie, nad którym pracuję potrzebuję aplikacji webowej, która umożliwi zarządzanie harmonogramami zadań. Ponieważ mam bardzo dobre doświadczenia z frameworkiem Django, postanowiłem zaryzykować i uruchomić go na wspomnianej płycie. Ryzyko wynika z faktu, że Python, w którym jest napisane Django, to język interpretowany i można mieć poważne obawy, czy 200MHz-owy mikrokontroler z 64MB RAM-u da sobie radę z tym zadaniem.
Buildroot, z którego korzystam ma w paczkach jedynie Pythona w wersji 2.4. Pomyślałem, że byłoby dobrze mieć nieco świeższą wersję, więc postanowiłem zmodyfikować patche i skompilować wersję 2.6. Nie było to łatwe zadanie, ale łącząc oryginalne patche Buildroota z tym, co udało mi się wygooglować otrzymałem działające rozwiązanie.
Oto patch, który należy umieścić w katalogu package/python/: python-2.6-001-multi.patch.
Należy też wyedytować package/python/python.mk:
PYTHON_VERSION=2.6.4 PYTHON_VERSION_MAJOR=2.6
w konfiguracji Buildroota należy wybrać Pythona w Package Selection for the target -> Interpreter languages / Scripting. Jeżeli chcemy korzystać z Django należy także pamiętać, że będziemy jeszcze potrzebowali bibliotek dla programistów, czyli python -> development files on target. Należy przy okazji zaznaczyć Build options -> development files in target filesystem, niestety wyraźnie zwiększy to ilość zajętego przez system miejsca, bo Buildroot dołączy mnóstwo plików nagłówkowych. Na koniec należy wybrać jakąś bazę danych. Myślę, że w przypadku aplikacji uruchamianych na systemie wbudowanym w zupełności wystarczy SQLite: Package Selection for the target -> Database -> sqlite.
A tak wyglądają u mnie newralgiczne fragmenty pliku konfiguracyjnego:
# BR2_HAVE_MANPAGES is not set # BR2_HAVE_INFOPAGES is not set # BR2_HAVE_DOCUMENTATION is not set BR2_HAVE_DEVFILES=y BR2_UPDATE_CONFIG=y BR2_PACKAGE_READLINE=y BR2_PACKAGE_SQLITE=y # BR2_PACKAGE_SQLITE_READLINE is not set BR2_PACKAGE_OPENSSL=y BR2_PACKAGE_NCURSES=y # BR2_PACKAGE_NCURSES_TARGET_PANEL is not set # BR2_PACKAGE_NCURSES_TARGET_FORM is not set # BR2_PACKAGE_NCURSES_TARGET_MENU is not set # BR2_PACKAGE_NEWT is not set # BR2_PACKAGE_SLANG is not set BR2_PACKAGE_PYTHON=y BR2_PACKAGE_PYTHON_DEV=y # BR2_PACKAGE_PYTHON_PY_ONLY is not set BR2_PACKAGE_PYTHON_PYC_ONLY=y # BR2_PACKAGE_PYTHON_PY_PYC is not set # BR2_PACKAGE_PYTHON_BSDDB is not set # BR2_PACKAGE_PYTHON_CODECSCJK is not set # BR2_PACKAGE_PYTHON_CURSES is not set # BR2_PACKAGE_PYTHON_PYEXPAT is not set BR2_PACKAGE_PYTHON_READLINE=y # BR2_PACKAGE_PYTHON_SSL is not set # BR2_PACKAGE_PYTHON_TKINTER is not set BR2_PACKAGE_PYTHON_UNICODEDATA=y
Po tych zabiegach Python powinien już działać, może jedynie wystąpić błąd podczas uruchamiania powłoki interaktywnej:
# python Python 2.6.4 (r264:75706, Mar 18 2010, 09:24:08) [GCC 4.3.4] on linux2 Type "help", "copyright", "credits" or "license" for more information. python: can't resolve symbol 'BC'
Rozwiązaniem jest dopisanie do target_skeleton/etc/profiles:
# Dla interaktywnego Pythona: export LD_PRELOAD=/usr/lib/libncurses.so
Jak dotąd nie napotkałem na żadne inne przeszkody. Django działa i współpracuje z SQLite, choć, rzecz jasna, demonem szybkości nie jest. Uruchomienie python manage.py runserver trwa wieki, ale gdy w końcu serwer wstanie, to działa w miarę sprawnie i zajmuje połowę RAM-u (ok. 30MB). Na razie jestem w stanie to zaakceptować, gdyż Django będzie w moim systemie główną aplikacją i nie jest problemem fakt, że pożera większość zasobów. Mam tylko nadzieję, że w połowie pracy nie zostanę zmuszony do przejścia na jakieś inne CGI.
