Some modifications in build process of libchamplain

[Jiří Techet <techet gmail com>]

Hi everyone,

I've made several modifications in libchamplain's build process
(modifications of configure.ac, makefiles) and some minor
modifications of the code (mainly python bindings):

* I made memphis renderer optional - this was the main purpose of my
modifications. You can now build libchamplain without memphis support.
The main reason is that while all other libchamplain's dependencies
are very standard ones, libmemphis is still very experimental and
requiring it may complicate libchamplain's distribution. If you wish
to use memphis, you now have to include <champlain-memphis.h> in
addition to <champlain.h> because the memphis interfaces are not
included in core libchamplain now.

* This change also meant that I had to do something similar with the
bindings - I *hope* I did it correctly for python bindings, but
because I haven't found any good documentation of how to make python
bindings for gtk applications and because there is no example of
memphis application for python yet, there may be many errors. (All
changes I made during the process were heavily inspired by what cairo
and clutter do.)

* There is a new champlain-features.h header generated by autoconf.
This is used for conditional compilation of some memphis features in
champlain_factory. I've also modified the sources to use it for maemo
conditional compilation. In this case config.h generated by autoconf
cannot be used because the macros appear in header files, so it has to
be in some separate header file that gets installed together with the
other headers (again inspired by cairo).

* I have used autoconf macros to generate library version _everywhere_
(at least I hope). There was 0.5 hardcoded so many times in the
makefiles that I can imagine it must have been a nightmare to make a
release and not to miss at least one.

* Many smaller fixes / portability improvements.

The result is here:

http://gitorious.org/~techy/libchamplain/techy-autoconf

I made it on top of Victor's python binding branch because I'm very
interested in python bindings and because I had to make some
modifications there so I rather wanted to do it with something working
rather than the outdated code. Then I rebased the code on top of
mainline, so the history looks like this:

mainline -> Victor's branch -> my changes

I haven't touched any other bindings so I'm not sure what changes will
be needed there (from what I could see, they haven't been updated for
the new code yet anyway).

So my question is what you think about it. I's affecting almost
everyone (bindings, memphis, core libchamplain), so it's possible that
there is something wrong in principle about this approach - would be
nice to know your opinion.

Taking into account the amount of changes, I'm almost sure I've
introduced some bugs. Please let me know about them too.

Jiri