Hi,
My problem is solved. Sorry for the inconvenience.
I've found out that almost all stuff was in the -internals header
file. It was just a matter of explictly making classes public. The
generated header file is finally complete. I thought that classes were
implicitly public (bad presumption).
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
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
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
On Sun, 2009-01-11 at 10:52 -0500, Yu Feng wrote:
Therefore my opinion on the cycles is that there should not be
unsolvable typedef cycles ( with .h, -priv.h and .c) in a properly
designed program, because these cycles represents solid cycles in your
Class atlas; which (as I can remember)
On Sun, 2009-01-11 at 08:49 -0800, Noah Gibbs wrote:
If you implemented the last solution, my current use case would always
require the -H option. But I may not be typical that way.
You will need -H for each library or application with plugin system.
However, not much we can do about that as
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
On Mon, 2009-01-12 at 14:32 +0100, Jürg Billeter wrote:
On Sun, 2009-01-11 at 10:52 -0500, Yu Feng wrote:
Therefore my opinion on the cycles is that there should not be
unsolvable typedef cycles ( with .h, -priv.h and .c) in a properly
designed program, because these cycles represents solid
Jürg Billeter wrote:
I want to finally solve issues we're having related to generation of C
header files. The current situation is that valac generates a .h file in
addition to a .c file for each .vala source file. The .h files describe
both, the public and the internal, C API.
There are
On Sun, Jan 11, 2009 at 3:14 PM, Jürg Billeter j...@bitron.ch wrote:
* Generate two sets of header files
For each source file foo.vala, we could generate foo-priv.h in
addition to foo.c and foo.h and move the internal C API there. One
issue with this approach is that it clutters the
On Sun, 2009-01-11 at 16:41 +0200, Arto Karppinen wrote:
Jürg Billeter wrote:
* Header file interdependencies
Header files often depend on other header files and sometimes these
dependencies form cycles. These cycles are currently detected by the
compiler and resolved as far as
My point on this.
I took a look at gtkwidget.c and gtkcontainer.c.
GtkWidget has a parent reference to GtkContainer so it should have
circular header files.
It turns out they avoid the cycle by defining the parent member of
GtkWidget as a GtkWidget instead of what it should be (GtkContaienr).
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
13 matches
Mail list logo
