The CAPI Manifesto

[Fawzi Mohamed]

The main problem with this approach is how to support different versions of a library, or of OS. It quickly becomes difficult to support anything but the latest, or a fixed version.
It works beautifully for mature libs.

I still cannot avoid thinking that a C frontend automatically generating D modules with the help of recipes would be a better way.
It will need some manual intervention for "difficult" cases, mainly giving manual translation of some macros, but it should be small.

One would set if all the files correspond to modules, or there are just some "main" directories/files.

Some things are easy:
#define a
enum { a=true }
#define b "xyz"
enum { b="xyz" }

one could be tempted to replace 
	#ifdef x
with
	static if (is(typeof(x)) && x)
and treat other #if in a similar way, but in D a static if must contain a full statement, as its content must be syntactically valid, whereas the C preprocessor does not have this limitation.
The way to work around this, if we create the headers on demand is simple: we already evaluate all #if using the building definitions of the associated C compiler (gcc -E -dD for example) and its default include paths (or directly use it, keeping in account the # line file directives).

real macros are more tricky, for example one could do

#define isSmall(x) (x<2)
isSmall(T)(T x){
	return x<2;
}

#define c(x) { x , #x }
template(alias x){
	{ x, x.stringof }
}

thus c(t) has to become c!(t).

and maybe one has to provide some macros definition by hand, but I guess the cases are not so much.

In all this there is still a major pitfall: redefinitions of the same macro. It is not common, but it happens, and when it does everything breaks.
One could give different names for the clashing symbols, but it remains ugly.
Furthermore in D one cannot define the same interface to a C function twice and import it in the same scope through two modules, because it will clash, even if private.

This makes the whole more complicated, but I think that a few recipes coding the exceptions like macro translations, macros/defs to suppress or rename it should work pretty well.

Once could analyze if different "views" of the same include file are compatible, and automatically check for double definitions.
It isn't an easy project, but it would be very useful if done correctly. I remember talking about it with Lindquist quite some time ago…

Fawzi