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.
> * Build performance
> As the internal API is in the header file as well, small changes can
> lead to a rebuild of the whole library or application. As the C
> compilation takes more time than the Vala compilation for larger
> projects, developers could profit from a vastly increased rebuild
> performance if we can solve this issue.
I agree, but if compile time is an issue, automake in combination with
ccache already saves you a lot of time for the things that haven't
changed.
> * 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.
> 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.
>
> I'm leaning towards the last solution as this solves all of the issues
> mentioned above and should also provide the simplest way to integrate
> into build systems such as automake. I can understand that some people
> might not like that solution as it deviates from the traditional way how
> you would do it in C. However, Vala is about practical solutions, not
> traditions.
I agree. The only case you need to dig into the generated .c files is
when something is not working as it is supposed to do.
Hans
_______________________________________________
Vala-list mailing list
Vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list
