Re: Libchamplain and GNOME 3.0

[Jiří Techet <techet gmail com>]

On Mon, Jun 14, 2010 at 13:59, Łukasz Jernaś <deejay1 srem org> wrote:
> On Sun, Jun 13, 2010 at 1:25 PM, Jiří Techet <techet gmail com> wrote:
>> On Fri, Jun 11, 2010 at 20:39, Łukasz Jernaś <deejay1 srem org> wrote:
>>> Hi.
>>>
>>> I hope this mail doesn't get too convoluted, but I wanted to branch
>>> the discussion into a separate thread and write some issues/ideas I
>>> have regarding the whole GNOME 3.0 thing. Hmm, ok, this issue came up
>>> on d-d-l when I was drafting this email, so forgive me some
>>> repetition.
>>>
>>> As it stands now libchamplain seems to be 3.0 compliant, but some of
>>> it's external dependencies are lacking. Clutter-gtk will be gtk+3
>>> compliant soon (as noted on desktop-devel-list) so that only leaves us
>>> with libsoup, which depends on libproxy. There I see a small problem,
>>> because libproxy is hosted outside the GNOME infrastructure and seems
>>> to use system wide GConf keys which aren't yet implemented in any way
>>> in GNOME 3.0, so until this arrives we can't move on. Also to minimal
>>
>> How about other gnome programs/libraries depending on libsoup? I think
>> libsoup is quite a frequently used library so what will they do and
>> how will it affect us? Is the affected part libsoup-gnome only or
>> something inside libsoup core?
>
> I think it's just libsoup-gnome that is affected, but frankly I have
> no idea how other apps will handle it.
>
>>> Vala version for 3.0 will be 0.9.2.
>>> Other that that (and the python bindings) we should be good…
>>>
>>> BTW Jiří can you make the Vala bindings enabled by default for 3.0?
>>
>> You mean --enable-vala to be used by default, right? I think this
>> should be possible as we distribute the .vapi and .deps files and only
>> copy them to the system with make install (I could remove the check
>> for the valac compiler in configure.ac actually - it's used only when
>> you run the create.sh script but not during make).
>
> Yes, but I would leave the check there, valac is needed to build the
> demo app and required it at build time may prevent some weird
> directory permission issues which may pop up.

Ah, yes, that's true. But in that case I would prefer not to have vala
bindings enabled by default to reduce the amount of the necessary
packages for libchamplain build (the remaining bindings aren't enabled
by default either). Why do you need it to be enabled?

Jiri