Re: [Vala] Header file generation
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: * Internal API The whole point of an internal API is that it is internal, and we should therefore aim to separate public from internal header files. Yes, that sounds like a very good idea. Could we extend this with G_GNUC_INTERNAL somehow? Something like: public class Foo { internal void bar () {}/** Hide bar */ } internal class Foo {/** Hide all methods */ public void bar () {} } Or is there a different way to achieve the same thing. Yes, we should definitively use G_GNUC_INTERNAL and your example is exactly how it is supposed to work. internal will be default for namespace members (as private namespace members are not supported), so you will be able to skip `internal' for non-exported top-level classes. Nice! * 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. Not sure if I understand correctly but do you mean avoiding internal headers altogether? I think giving vala full control to decide which definitions/prototypes need to be declared in the individual .c files is probably the most easy and clean solution to overcome the header dependency hell. It might speed up the overall compile time too. Yes, you understand it correctly, vala wouldn't use any internal header files anymore. It will just include header files for external (C or Vala) libraries, and it will generate a header file for the public API when using -H. 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? Regards, Hans ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Header file generation
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 ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Header file generation
On Mon, 2009-01-12 at 18:38 +0100, Philip Van Hoof 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. So let valac copy what would end up in -priv.h files into each .c file being generated? Well, the .c is not for human eyes nor hands to see nor modify, so that's okay for me. You kinda loose the capability of interfering from a manual .c file, like I described in this example (although the particular example wouldn't be affected): http://live.gnome.org/Vala/MultiImplementInC I don't think that this would have a large effect when combining C and Vala in the same library. The only difference is that you get one instead of multiple .h files per valac invocation. If you want to be able to access internal Vala methods from the C part, we can certainly add a --header-internal option to generate a -priv.h file. Jürg ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list