Re: [Vala] Header file generation

[Hans Vercammen <hveso3 gmail com>]

On Tue, 2009-01-13 at 23:27 +0100, Jürg Billeter wrote:
> 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 agree. However, I'm still thinking in terms of not having reached 1.0
yet :)

> 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.

Yes, that would be a good option and definitely usable! But that way
there is no catching in vala whether the use of internal api is actually
valid. Regarding the merging, I see this as some sort of fail-safe for
the link process. Linking the same (public) statics and dynamics is in
most cases just bad practice anyway. You do have a good point about the
header files though.

Hans