Re: [Vala] .gir and .metadata file warnings and errors

[Jim Nelson <jim yorba org>]

On Wed, Dec 11, 2013 at 3:47 PM, Evan Nemerson <evan coeus-group com> 
wrote:
> Don't use the GIR directly.  GIRs take forever to parse anyways, why
> parse it every time you run valac?  Use vapigen (without fatal 
> warnings
> enabled) to parse the GIR to a VAPI, then use the VAPI.

... which means we're compiling against the bindings for a particular 
version of the library.  That's not always desirable or practical.

> I would love to configure different errors/warnings to do different
> things (like you can with -ffoo, -fno-foo, -ffatal-foo for gcc).  This
> wouldn't be particularly difficult to do with valac/libvala, it just
> needs a bit of light refactoring and some easy (but time-consuming)
> effort to enumerate, name, and maybe categorize every possible error.

I'd like this too.  My motivation for describing this problem is to 
suggest one large categorization of errors and warnings: how bindings 
and metadata files are being processed.

Another possibility would be for each error and warning to have a code 
or number printed with it.  A generic enable/disable flag could accept 
that code.  This gives fine-grained control without having to enumerate 
all classes of warnings or errors ahead of time.

> By default the problem that vala really can't deal with
> intelligently (conflicting symbol) is an error, and the one it can 
> deal
> with (unused metadata) is a warning, which seems quite reasonable to 
> me.

With the first situation, it happens to be a symbol that valac doesn't 
have to generate code for.  From a user perspective, valac is acting as 
a kind of .gir validator here, which I'm questioning.

With the second, I would normally agree, but because bindings are 
always in flux, symbols may be added and removed with each release.  We 
now have to maintain multiple .metadata files in order to build on 
various distros.  That's why I would like to be able to disable the 
metadata warnings (which I'm not saying should be removed).

-- Jim