On Fri, Feb 22, 2013 at 11:05 AM, Eric Gregory <[email protected]> wrote:
> On Fri, Feb 22, 2013 at 3:41 AM, Evan Nemerson <[email protected]> wrote:
>>
>> I've created a repository on GitHub ("vala-extra-vapis" [1]) to house
>> our external VAPIs.
>>
>> This repository has a very low barrier for entry.  Unlike the bindings
>> distributed with valac, I don't plan to provide much review or
>> oversight.  Basically, the only requirement for getting bindings into
>> the repository is an open source license (preferable MIT or a similarly
>> permissive license).
>>
>> vala-extra-vapis is designed to be used as a git submodule, and it will
>> only contain *.vapi and *.deps files (as well as the README).  All
>> tests, examples, documentation, and other supplemental information will
>> go in a second repository, "vala-extra-vapis-supplemental" [2] (yes, I'm
>> aware the name seems both repetitive and redundant).  I'm still working
>> on getting the infrastructure in place to automatically run the tests
>> and generate documentation, but that should happen soon.
>>
>> If you have created bindings for libraries which are not being
>> distributed with the library they bind (or with valac), I hope you'll
>> consider submitting them for inclusion in vala-extra-vapis through the
>> issue tracker on GitHub.
>>
>> Just to be clear, I still prefer that bindings be distributed with the
>> library they bind when possible (see [3]).  However, I hope this will
>> provide an easier alternative to trying to get them distributed with
>> valac.
>
>
> Evan,
>
> That's a great idea! What do you think about opening up this repo for
> metadata files as well?

Metadata, as well as *-custom.vala and any other tooling necessary to
generate bindings can in the vala-extra-vapis-supplemental repository.
The generated bindings themselves can go into vala-extra-vapis
repository.

Note, however, that I don't plan to regularly regenerate bindings like I
do for those shipped with valac.  Instead, I would like to rely on pull
requests from others.

> I ask because we're using WebKitGTK via the GIR binding, but it requires a
> number of fixes in the metadata file to work correctly.  It would be great
> if we could share these changes with other projects.

The WebKitGTK+ people were willing to distribute Vala bindings with
WebKit.  If that is still the case then that is what should happen, for
the reasons listed in the upstream guide, which are mostly the same
reasons I'm not excited about the possibility of distributing them with
valac.  WebKitGTK+ is a large API (actually, several large APIs), and
beyond generating a lot of churn I'm sure there will be a fair number of
issues from targeting the wrong version due to a mismatch between the
installed library and the version used to generate the VAPI.


-Evan
_______________________________________________
vala-list mailing list
[email protected]
https://mail.gnome.org/mailman/listinfo/vala-list

Reply via email to