Re: [Vala] Header file generation

[Jürg Billeter <j bitron ch>]

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 possible - for example, by moving
> >    typedefs to other header files and reordering includes.
> >
> >    While this works in many cases, there are situations that cannot be
> >    solved with the current approach, depending on what type you declare
> >    in what .vala file. There are also situations that could be solved
> >    with the current approach but are not implemented yet; it would
> >    complicate the code even further.
>
> It should be possible to handle the typedef problem by simply defining 
> all typedefs before any includes in .h files and putting all includes 
> after typedefs. Something like this:
>
> #ifndef __HEADER__
> #define __HEADER__
>
> // ALL typedefs here.
> typedef gint my_int;
> typedef void (*functionpointer) (gint i);
> typedef struct _MyClass MyClass;
>
> // ALL includes here.
> #include "something.h"
> #include "other.h"
>
> // Everything else below
> struct _MyClass {
>     ...
> };
>
> void function_a(gint a, gint b);
>
> #endif
>
> If you do this, then it does not matter in which order you include
> the 
> headers, typedefs are always defined as long as you include the
> correct 
> header. The point of this ordering is to achieve a situation where
> all 
> typedefs are defined before any other part of the header files are 
> parsed by the compiler. Once all typedefs are defined, it does not 
> matter in which order the rest of the headers are parsed.

This does not work in all cases, unfortunately. A simple example is if
the parameter type of a delegate is declared in another file.

Another example is the situation where you have class A declared in
A.vala and class B declared in B.vala. B is a subclass of A, so it needs
to include "A.h". A has a method that takes an object of type B as
argument, so it needs to include "B.h".

The issue now occurs with the combination of header guards to avoid
multiple inclusion. If you first include "A.h" from some .c file, it
will process the typedef for the struct A, then include B.h, which will
add the typedef for struct B.

B.h will then try to include A.h, however, nothing will be processed as
the header guard prevents multiple inclusion. The following definition
of the struct B requires the definition of struct A, which will only be
processed after B.h has been read completely, so this will result in a C
compiler error.

Jürg