On Thu, 2013-12-12 at 00:26 -0008, Jim Nelson wrote:
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.
You can still do this step as part of your build process—you don't need to include the generated VAPI in your repository. If you're worried about the user updating WebKit between Geary compilations while there is a VAPI in the build directory, that shouldn't really be an issue since build systems don't usually detect changes in C header files, so people already know to make clean in those situations. That said, even if you do decide to ship the VAPI in your repo (or dist tarball), it probably would not be an issue. There are a few cases where a VAPI being too new can cause problems, but if you use a VAPI from the lowest version of WebKit you want to support it can actually improve things by preventing you from accidentally depending on features from a newer version of WebKit. The big drawback is you don't get fixes from newer versions (especially for things like ownership), but such fixes tend to be few and far between for API which someone is actually using, and you only care about API you're using... Of course, in a perfect world WebKit would ship a VAPI themselves, but I'm through tilting at that particular windmill.
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.
I would want the code to be some sort of identifier (so I could do something like --disable-warnings=foo,bar,baz), which would still require going through an enumerating all the different errors. Not difficult, but time consuming.
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.
Doesn't matter. The entire GIR gets parsed and symbols get resolved just like you were parsing a VAPI. I understand what you're suggesting, and it would be cool, but there are practical and architectural concerns here which prevent that sort of lazy parsing. Frankly, unless you (or someone else) want to rewrite a significant portion of valac (including pretty much all of the GIR parser), it's just not going to happen. And even if you did, I doubt anyone would want to maintain it because the compiler would probably be a complete mess.
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).
Or you could do what I suggested and just generate a VAPI, and ignore (or disable) warnings during vapigen. Your compilation times will usually be lower and you will have a nice easy-to-read definition of the API you're trying to use. -Evan
Attachment:
signature.asc
Description: This is a digitally signed message part