Saturday, August 7, 2010

Easy way to setup build environment for Windows on Linux

Microsoft Windows is still the most popular desktop OS but not the most pleasant for the developers. Especially if you are creating open source application.
The MingW project delivers GCC and the tool-chain for building applications for Windows. Most popular libraries are also portable.
So it is possible to setup the cross-compilation environment to build Windows applications on Linux (Unix) system. But if you need to port the applications it is not always easy to get all the required libraries.
Yesterday I have discovered very convenient tool to setup MinGW cross compiling environment.
This tool, mingw-cross-env automatically downloads and builds mingw and several most popular libraries including Qt and GTK+.
To build my old ebook converter fit2pda I had to do the following steps.
  1. Download mingw-cross-env and build the required libraries (Qt):

    tar xzf mingw-cross-env-2.15.tar.gz
    cd mingw-cross-env-2.15
    make qt
  2. Setup PATH - add the string

    export PATH=/where mingw-cross-env is installed/usr/bin:$PATH
    to .bashrc

  3. Cross-compile fit2pda

    cd ~/projects/fit2pda
    i686-pc-mingw32-qmake
    make

That's all!
And the Windows version of the application is available.

Sunday, August 1, 2010

Django-nonrel on Google App Engine

This spring I've started to use Google App Engine. It supports the usage of Django but in the limited form. For example, Django admin interface (django.contrib.admin) and authentication (django.contrib.auth) don't work by default. The root of the problem is the lack of a relational database on Google App Engine. Key-value storage is used instead.

Google offers to use google accounts and internal administrative interface. It was good enough for my first project Blun.ch, which was created in two days during the HackDay. But now I'm starting the commercial project PsychoTool, and I don't want to be locked in the Google's infrastructure. Also I need the control over the admin interface, so django.contrib.admin is really helpful. Luckily, it is possible to design django applications in such a way that they can be ported from Google App Engine to the standalone django installation. The modified version of Django is required. It supports non-relational data storage. This version is created in the Django-nonrel project. This project is not mature yet, but pretty stable and usable. The documentation is a bit terse, but the discussion group is really helpful.

I was able to build simple application with multiple related data sets and use the Django admin interface deployed on the Google App Engine.

I had the following difficulties with the models and deployment.

  • It seems that if one uses "ForeignKey" fields in the models, he is to specify "related_name" property if he want to have the corresponding field in another model.
  • The deployment has failed several times due to the problems with the authentication. The workaround for me was to authenticate once using appcfg.py from appengine SDK instead of manage.py from django-nonrel. The other problem due to the building of indices on Google App Engine. This process takes some time and requires patience.

If you want to develop Django applications which work on Google App Engine and regular Django setup do not hesitate to try Django-nonrel!
I will be happy to help you if you have some problems.

Posted via email from antonnaz