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.

Dodawanie komentarzy

XHTML: Możesz używać tagów: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong> <pre lang="" line="" escaped="">