Re: [Vala] Header file generation

[Arto Karppinen <arto karppinen mail suomi net>]

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 various issues with the current approach:
>
>  * 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.

You mentioned only typedefs, are there other kinds of circular 
dependencies that cause problems?

--
Arto Karppinen
------------------------------
arto karppinen iki fi