Re: [ANNOUNCE] libchamplain 0.6

[Jiří Techet <techet gmail com>]

On Mon, May 31, 2010 at 08:03, Tomaž Vajngerl <quikee gmail com> wrote:
> On Sun, May 30, 2010 at 11:40 PM, Jiří Techet <techet gmail com> wrote:
>> 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.
>
> I will try to manually specify the header files and I will see if it
> goes or not. I think it should go but I was already burned by guessing
> when I thought that bindings generation from gobject-introspection
> files in vala works as good as old one.
>
>> 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.
>
> Vala is similar:
> 1. vala-gen-introspect generates the .gi file (automatic)
> 2. You specify overrides and other information in .metadata, .deps and
> others but this is usually done once unless a big change occurs  (in
> gobject-intrspection this step is done in the code itself) (manual)
> 3. vapigen generates .vapi file from .gi file and overrides (automatic)
>
> .vapi file (and also .deps file to specify the dependencies) is the
> only thing needed by vala for the bindings and this changes only when
> API changes.
>

I understand now - .gi corresponds to .defs in Python bindings - my
original impression was that .gi is the final product. Don't worry
about completely automatic bindings generation - the way you do it now
is perfectly OK. So please just explore if bindings for memphis can be
omitted if libchamplain is compiled without memphis support.

>> 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.
>
> Well I think everything except from overrides, the whole procedure can
> be made automatically at build time but I don't think we would gain
> anything because every time the vapi file will be the same - unless
> the API changes but in a release this is not the case. Also we know

Yes, that's the same reason why Python bindings are also made in a
semi-automatic way. As I said, this is OK.

> when there are API changes and we can rebuild the bindings at that
> time via a shell script (like in python bindings) and if necessary
> adjust the overrides.
> To make this procedure in build time you have to have
> "vala-gen-introspect" and "vapigen" tools available and it takes
> additional build time for everyone and no gain with additional risk
> that something could go wrong because of different configuration.
>
> I will make that the whole procedure is performed at (normal) build
> time but this should not be a priority or a showstopper for the
> bindings. What is important is that the procedure except for the
> overrides is automatically triggered by updaate script, which already
> is so - just the update script is currently incomplete.
>
>> 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...
>
> This is OK - however it would be nice to have access to the underlying
> osm xml files because I can imagine someone would want to calculate
> routes from one place to another. I don't know how is fetching of osm
> xml data currently done in memphis and champlain but have this
> use-case in mind when you re-architecture for 0.8.
>

This should be no problem because the xml data will be just gchar * so
you won't need any memphis-specific data strucutre.

Jiri

> Regards,
> Tomaž
>