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 _______________________________________________ Vala-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/vala-list
