Re: [Vala] Header file generation

[Jürg Billeter <j bitron ch>]

On Tue, 2009-01-13 at 23:01 +0100, Hans Vercammen wrote:
> On Mon, 2009-01-12 at 14:43 +0100, Jürg Billeter wrote:
> > On Mon, 2009-01-12 at 08:40 +0100, Hans Vercammen wrote:
> > > On Sun, 2009-01-11 at 14:14 +0100, Jürg Billeter wrote:
> > > >  * Minimize use of header files
> > > >    A more radical approach would be to not use header files where not
> > > >    necessary. The Vala compiler could insert required declarations at
> > > >    the top of each generated .c file and only use include directives for
> > > >    external libraries. This would lead to optimal rebuild performance at
> > > >    the cost of a bit larger .c files.
> > > >
> > > >    We obviously still need to support generating header files to use
> > > >    libraries written in Vala. I would propose to add an option -H foo.h
> > > >    to valac to generate a single header file with the full public C API.
>
> Looked somewhat deeper into your proposal and see some issues when you
> have a more complex source tree. Related to the build tools; how do you
> see the use of "internal" across libtool convenience libraries? I think
> it would be nice to access these internal apis, so you need a common
> -priv.h file and inclusion in the .vapi file too.
>
> In theory I guess we could mark those .vapi files as internal somehow
> and even apply the same principles (declare directly into .c files). In
> latter case the compiler probably would get overly complex and we lose
> the autotools C dependency tracking mechanism, so I'm not sure if that's
> even wanted though.
> However, something like --library and --static-library, where you
> automatically merge the statics and exclude the internals in the
> generated .vapi file when --library is used. Might have missed some
> essential blockers or design goals for this proposal, but what do you
> think of it?

I'm not sure yet how to improve support for libtool convenience
libraries, as they are used in different ways in different projects
(regarding function exporting and API merging). I think that we can
build functionality for convenience libraries on top of the current
proposal, so I'll postpone thinking about this in detail. There should
be no regression compared to the current implementation in that regard.

I'm not opposed to, for example, adding --header-internal and
--vapi-internal options to allow the generation of .h and .vapi files
for the internal API. This should be quite easy to add later on. Not so
sure about merging .vapi (and .h?) files.

Jürg