Ok,
I need some clear definition of the policy around
extern/external/external_package.
1) external == true if extern or external_package.
2) vapigen actually works on PACKAGE first then switch to SOURCE after
because code writer skips namespaces that are external_package.
3) In switch-to-gir I work on SOURCE instead of doing the switch, this
requires some fixing for external usage.
3.1) There are some checks like this:
(!is_abstract && !external && source_type == SourceFileType.SOURCE &&
body == null)
that I'd rather convert to:
(!is_abstract && !external && body == null)
This works when using vapis but breaks:
1) gidlparser because created methods have no .external set
2) maybe (untested) fast vapis
3) other code?
So main questions:
1) Should vapigen do:
1a) Use PACKAGE initially then switch to SOURCE for codewriter, like it is
now, and do not do the change above, but I feel everything a little
incoherent
1b) Use SOURCE (but really from a Vala pov it's a package, only for vapigen
is a SOURCE) and make vapigen set .external = true for all symbols
2) Should add a bool extern; to symbols and make external { get { extern ||
external_package } }, or keep it like this but then we need some clear
policy about it.
3) How codewriter should behave? What external stuff should be written? Does
it make sense to write extern stuff?
In other words, I don't know for sure the design of external & code writer,
but I feel there's the need to clear things out. I especially dislike the fact
that we tune SOURCE/PACKAGE/external to tweak code writer output, I don't
see a clear type SOURCE/PACKAGE for vapigen usage because there's no
absolute definition of those types.
Maybe I forgot something to say but hopefully you understood my idea.
Best regards,
--
http://www.debian.org - The Universal Operating System
Attachment:
signature.asc
Description: Digital signature