Re: [ANNOUNCE] libchamplain 0.6

[Tomaž Vajngerl <quikee gmail com>]

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.

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

Regards,
Tomaž