Re: [ANNOUNCE] libchamplain 0.6

[Tomaž Vajngerl <quikee gmail com>]

On Sun, May 30, 2010 at 1:20 PM, Jiří Techet <techet gmail com> wrote:
> I've just looked at your vala bindings support and I have a few comments:
>
> 1. There seems to be a misunderstanding how memphis support should be
> done - it should be always possible to compile bindings with/without
> support of memphis. Please look at the python bindings that I made the
> way that it's possible to compile them with/without memphis support.
> Also please see my answer here
>
> https://bugzilla.gnome.org/show_bug.cgi?id=619908
>
> to understand how memphis support is supposed to be checked by the
> applications. For instance Emerillon shouldn't require that
> memphis-enabled libchamplain is installed no matter what bindings are
> used.

OK I understand now, however this can be a pain - generally
vala-gen-introspect tool works in that way that it scans the source
code. If he finds somewhere a #include that is not stated in the
champlain-0.6.pc file it fails and doesn't even generate a .gi file
which is then needed to create the actual bindings. I will try to
define all the header files that are needed manually instead of the
whole folder - if this even works. Otherwise would it be possible to
separate memphis specific to a separate source folder like
champlain-gtk?

> 2. Is there any reason why the bindings are not generated during make?
> I would prefer not to commit things that can be generated
> automatically. I did it for 0.4 just as a quick patch but for 0.6 I'd
> prefer the correct solution.

The reason is that in order to do this automatically nothing needs to
be manually adjusted to build the bindigns. This was not the case
before that is why I didn't do it yet. Currently the need to separate
bindings depending on libmemphis is such a issue and when I solve this
I will make them build automatically. I also wanted to make it step by
step to make it work as in champlain 0.4 first and didn't know this is
a priority.

Correct me if I am wrong but Python bindings also are not "refreshed"
automatically in build time - you still have to call
"update-bindings.sh" when the API changes.

> 3. A more general thing related to bindings - am I right that the only
> reason we need bindings for memphis is the MemphisRule structure that
> is passed as an argument to champlain_memphis_tile_source_set_rule() ?
> Are there any more places where memphis interface is visible to the
> applications using libchamplain? If this is the only place then it
> would be much better to have e.g. ChamplainMemphisRule structure that
> is used instead of MemphisRule in libchamplain and which would hide
> all the memphis interface so bindings will not have to be aware of
> memphis. This would just eliminate the problem in (1). This would be
> possible for libchamplain 0.7 only because it breaks the API
> compatibility.

There is also MapDataSource -> get_map_data which returns a Memphis Map.

Regards, Tomaž