Re: [ANNOUNCE] libchamplain 0.6

[Jiří Techet <techet gmail com>]

On Sun, May 30, 2010 at 22:31, Tomaž Vajngerl <quikee gmail com> wrote:
> 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?

I was thinking about moving the code into subdirectories of champlain,
but these would have rather more general form like:

map-sources
renderers
layers

(champlain directory would contain only the core functionality)

and not specific for the given source. However, if it is possible to
manually specify the list of files for which you want to generate the
bindings, it should be pretty easy - just look at champlain-memphis.h
and all the includes (apart from champlain-features) + the
corresponding sources are only used for memphis support. They are not
included by any other part of libchamplain.

>
>> 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.
>

I have not studied how the vala bindings generation works but for
python it's a three-stage process:

1. You generate the .defs files (automatic)
2. You create the .override files (manual)
3. You compile the bindings (automatic)

Because if the interface changes you often have to manually change the
.override files, the automatic .defs file generation is not done
during make because it has to be followed by the manual modification
anyway. So the .defs files are created by manually calling the script
(which also has the advantage you can then compare the old .defs with
the new .defs to see what has changed and what .override files have to
be updated). The third stage is performed during the normal build.

Isn't something like that possible for vala as well? I'm not totally
sure what the manual input is - I expect these are the .deps and .vapi
files, right? So what I propose is that just the .gi file gets
generated automatically and the rest can be just manually updated
every time the interface changes. I really know nothing about how vala
binding generation works so please correct me if I talk complete
nonsense here.

>> 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.
>

Aha, have overlooked this. Great, this will get completely hidden
after implementing the first of my suggestions for 0.8 :-). It's just
used internally by the memphis rendering part and shouldn't be
available in the interface. So it looks that all the libmemphis data
structures can be completely hidden by libchamplain so libmemphis will
be only internal dependency but not a dependency visible in its
interfaces.

libchamplain 0.6 will be a slightly experimental version related to
libmemphis and bindings...

Jiri

> Regards, Tomaž
>